Re: pgsql: Fix double-release of spinlock
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@iki.fi>, pgsql-committers@lists.postgresql.org
Date: 2024-07-29T16:18:46Z
Lists: pgsql-hackers
Hi, On 2024-07-29 11:31:56 -0400, Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas@iki.fi> writes: > > Commit 9d9b9d46f3 added spinlocks to protect the fields in ProcSignal > > flags, but in EmitProcSignalBarrier(), the spinlock was released > > twice. With most spinlock implementations, releasing a lock that's not > > held is not easy to notice, because most of the time it does nothing, > > but if the spinlock was concurrently acquired by another process, it > > could lead to more serious issues. Fortunately, with the > > --disable-spinlocks emulation implementation, it caused more visible > > failures. > > There was some recent discussion about getting rid of > --disable-spinlocks on the grounds that nobody would use > hardware that lacked native spinlocks. But now I wonder > if there is a testing/debugging reason to keep it. Seems it'd be a lot more straightforward to just add an assertion to the x86-64 spinlock implementation verifying that the spinlock isn't already free? Greetings, Andres Freund
Commits
-
Fix double-release of spinlock
- 0393f542d72c 18.0 cited
-
Move cancel key generation to after forking the backend
- 9d9b9d46f3c5 18.0 cited