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

[Frederic Weisbecker <frederic@kernel.org>]

Le Wed, Sep 09, 2026 at 02:45:55PM +0200, Peter Zijlstra a écrit :
> On Wed, Sep 09, 2026 at 02:13:11PM +0200, Frederic Weisbecker wrote:
> 
> > > > I argue that's not possible:
> > > > 
> > > > A:   sigqueue stores
> > > > 
> > > > B:   AQUIRE tasklist
> > > > 
> > > > C:   exit_state store
> > > > 
> > > > D:   RELEASE tasklist
> > > > 
> > > > E                               ACQUIRE tasklist
> 
> > > > F                               if (exit_state)
> > > > 				    	swap_pid()
> > > > G                                   STORE_PID
> > > > 
> > > > 				      RELEASE tasklist
> > > > 
> > > > H                                                       READ PID
> > > > 							      ....
> > > > I                                		              ACQUIRE siglock
> 
> > > Let G' be the unnamed RELEASE after G.
> > > 
> > > Now, I have deleted and rewritten this tail end at least twice now. And
> > > I *think* I'm agreeing with you. Let me explain:
> > > 
> > > It all hinges on D-E and H-I.
> > > 
> > > D-E is a UNLOCK+LOCK hand-over, which is not quite the same as
> > > RELEASE+ACQUIRE. Specifically, we have:
> > > 
> > >   RELEASE+ACQUIRE: RCpc,  only the CPUs involved agree on the ordering
> > >   UNLOCK+LOCK:     RCtso, the hand-over is store-ordering
> > > 
> > > So while earlier I was arguing with RCpc in mind, in which case D-E
> > > completely goes away and we can consider B-G' to be one big critical
> > > section from the PoV of a third CPU (our posix_timer_fn() one). In this
> > > case we can push A down and G up and have them cross.
> > > 
> > > *However*, since these are locks, we actually have D-E be UNLOCK+LOCK,
> > > which is RCtso and that *does* impose store order, so A stores must
> > > happen before G stores
> > > 
> > > Combine with H-I, which has a data dependency from the LOAD to the LOCK
> > > and thereby constraints later LOADs, those sigqueue loads that come
> > > after I must in fact observe the A stores.
> > 
> > I didn't know about all those UNLOCK+LOCK properties. Well,
> > I know that UNLOCK+LOCK on the same lock, or on different locks
> > but the same CPU, equals smp_mb() except on powerpc. Which is why
> > we have smp_mb__after_unlock_lock(). But what you describe is quite
> > different.
> > 
> > Is this something that we should expect litmus to modelize?
> 
> IIRC these commits:
> 
> 6e89e831a901 ("tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire")
> ddfe12944e84 ("tools/memory-model: Provide extra ordering for unlock+lock pair
> on the same CPU")

I didn't know that UNLOCK+LOCK can pair with smp_load_acquire(). Good to know.

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 *)

But yeah there is no data dependency involved. Let me answer to
that to tglx.

-- 
Frederic Weisbecker
SUSE Labs