Re: [patch V2 1/8] signal: Prevent exec() race

[Alan Stern]

On Wed, Sep 09, 2026 at 04:45:15PM +0200, Frederic Weisbecker wrote:
> I didn't know that UNLOCK+LOCK can pair with smp_load_acquire(). Good to know.

I don't know what that means.  Regardless, LOCK doesn't pair with 
smp_load_acquire().  UNLOCK does, but only to the extent that acts as a 
release.

> But unlock+lock doesn't pair with unlock+lock on different CPU.
> 
> C MP+polocks
> 
> {}
> 
> P0(int *A, int *B, spinlock_t *mylock)
> {
> 	spin_lock(mylock);
> 	WRITE_ONCE(*A, 1);
> 	spin_unlock(mylock);
> 	spin_lock(mylock);
> 	WRITE_ONCE(*B, 1);
> 	spin_unlock(mylock);
> }
> 
> P1(int *A, int *B, spinlock_t *otherlock)
> {
> 	int r0;
> 	int r1;
> 
> 	r0 = READ_ONCE(*B);
> 	spin_lock(otherlock);
> 	r1 = READ_ONCE(*A);
> 	spin_unlock(otherlock);
> }
> 
> exists (1:r0=1 /\ 1:r1=0) (* Bad outcome happens *)

I can't tell what you're trying to do here.  The UNLOCK-LOCK ordering 
in P0 means that P1 sees A=1 before it sees B=1.  But nothing in this 
litmus test forces P1 to execute READ_ONCE(*b) before READ_ONCE(*A).  If 
the reads are executed in the opposite order, you can see how P1 might 
get r0=1 and r1=0.

If P1 had done this instead:

P1(int *A, int *B)
{
	int r0;
	int r1;

	r0 = READ_ONCE(*B);
	smp_rmb();
	r1 = READ_ONCE(*A);
}

then r0=1 and r1=0 would be impossible.

Alan Stern