From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <heikki.linnakangas@iki.fi>
cc: pgsql-committers@lists.postgresql.org, Andres Freund <andres@anarazel.de>
Subject: Re: pgsql: Fix double-release of spinlock
In-reply-to: <E1sYSF2-001lEB-D1@gemulon.postgresql.org>
References: <E1sYSF2-001lEB-D1@gemulon.postgresql.org>
Comments: In-reply-to Heikki Linnakangas <heikki.linnakangas@iki.fi>
	message dated "Mon, 29 Jul 2024 15:24:52 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2600756.1722267116.1@sss.pgh.pa.us>
Date: Mon, 29 Jul 2024 11:31:56 -0400
Message-ID: <2600757.1722267116@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2600757.1722267116%40sss.pgh.pa.us>
Precedence: bulk

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.

			regards, tom lane