Re: Detect double-release of spinlock
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2024-07-29T18:00:35Z
Lists: pgsql-hackers
On 29/07/2024 20:48, Andres Freund wrote: > On 2024-07-29 13:25:22 -0400, Tom Lane wrote: >> Heikki Linnakangas <hlinnaka@iki.fi> writes: >>> Yeah I'm not worried about that at all. Also, the assert is made when >>> you have already released the spinlock; you are already out of the >>> critical section. >> >> Not in the patch Andres posted. > > Which seems fairly fundamental - once outside of the critical section, we > can't actually assert that the lock isn't acquired, somebody else *validly* > might have acquired it by then. You could do: bool was_free = S_LOCK_FREE(lock); S_UNLOCK(lock); Assert(!was_free); Depending on the underlying implementation, you could also use compare-and-exchange. That makes the assertion-enabled instructions a little different than without assertions though. > However, I still don't think it's a problem to assert that the lock is held in > in the unlock "routine". As mentioned before, the spinlock implementation > itself has never followed the "just straight line code" rule that users of > spinlocks are supposed to follow. Agreed. -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Fix double-release of spinlock
- 0393f542d72c 18.0 cited
-
Move cancel key generation to after forking the backend
- 9d9b9d46f3c5 18.0 cited