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

[Alan Stern]

On Wed, Sep 09, 2026 at 10:49:30PM +0200, Thomas Gleixner wrote:
> On Wed, Sep 09 2026 at 15:28, Alan Stern wrote:
> > On Wed, Sep 09, 2026 at 04:45:15PM +0200, Frederic Weisbecker wrote:
> > 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.
> 
> The problem we are debating is:
> 
>     C = VAL1
> 
>     CPU0                    CPU1		CPU2
>     
>     STORE(A0, 0)
>     STORE(A1, 0)
> 
>     LOCK(TLOCK)
>     STORE(B, 1) // 0 -> 1
>     UNLOCK(TLOCK)
> 
>                            LOCK(TLOCK)
>                            b = LOAD(B)
>                            if (b)
>                               STORE(C, VAL0)
> 
>                                                 c = LOAD(C)
>                                                 LOCK(c->lock)
>                                                   a0 = LOAD(A0)
>                                                   if (!a0)
>                                                      STORE(A0, X1)
>                                                      STORE(A1, X2)
> 
> The question is whether CPU2 can observe C == VAL0 and A0 == NULL before
> A1 has completed.
> 
> My and Peter's argument is that the sequence
> 
>    UNLOCK(TLOCK) on CPU0   -> LOCK(TLOCK) on CPU1
> 
> implies RCtso and therefore the stores to A0 and A1 on CPU0 must be
> before the store to C on CPU1.
> 
> Now because the LOAD(C) on CPU2 depends on that STORE(C) the
> LOCK(c->lock) ensures that LOAD(A0) can't be reordered and because of
> that STORE(A1, 0) has completed before that.
> 
> CPU2 LOAD(C) observing VAL0 has a data dependency on the STORE(C, VAL0)
> on CPU1, which as argued above can only happen after the UNLOCK/LOCK
> sequence CPU1 observes the STORE(B).
> 
> Subsequently LOCK(c->lock) has a data dependency on LOAD(C) and the LOCK
> operation prevents that LOAD(A0) can be reordered before LOCK(c->lock).
> 
> So despite the fact that c->lock != TLOCK the UNLOCK(TLOCK)/LOCK(TLOCK)
> sequence, which implies RCtso, the following takes care of it:
> 
>     1) the data dependency between the STORE(C, VAL0) on CPU1 and the
>        c = LOAD(C) on CPU2 observing VAL0
>    
>     2) the data dependency of LOCK(c->lock) on #1
> 
>     3) due to LOCK() in #2 LOAD(A0) cannot observe the STORE(A0, 0) on
>        CPU0 without the STORE(A1, 0) on CPU0 has completed.
> 
> If #3 can happen then that would obviously cause undebuggable data
> corruption.
> 
> I hope this is understandable enough despite my brain having melted
> several times by now while writing it up.

I see.  Yes, your analysis is right.  And Frederic's latest LKML litmus 
test confirms the result.

Alan Stern