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

[Alan Stern]

On Wed, Sep 09, 2026 at 02:45:55PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 09, 2026 at 02:13:11PM +0200, Frederic Weisbecker wrote:
> > 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")
> 
> Were supposed to handle:
> 
> 	CPU0		CPU1
> 
> 	UNLOCK(A)
> 			LOCK(A)
> 
> and
> 
> 	CPU0
> 
> 	UNLOCK(A)
> 	LOCK(B)
> 
> respectively. I'm forever confused by the actual CAT stuff, nor am I
> particularly adept at these litmus things. Boqun, Alan?

You got it right.  The required ordering is that instructions before 
(and on the same CPU as) the unlock are ordered before instructions 
after (and on the same CPU as) the lock for read->read, read->write, and 
write->write cases, but not for write->read cases.  Furthermore, this 
ordering requirement applies from the point of view of all CPUs, whether 
they access the lock variables or not.  In other words, the ordering is 
required to be RCtso.

This ordering is weaker than full smp_mb() in two respects:

	As mentioned above, it doesn't order earlier writes against
	later reads;

	In the WRITE->WRITE case, the guarantee is only that each CPU
	will observe the first write before it observes the second.
	There is no guarantee that _every_ CPU will observe the first
	write before _any_ of them observe the second.

Alan Stern