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

[Thomas Gleixner <tglx@kernel.org>]

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.

Thanks,

        tglx