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

[Alan Stern]

On Fri, Sep 11, 2026 at 02:27:56PM +0200, Frederic Weisbecker wrote:
> What I would love to see documented for example is our case: acquire semantics,
> which are described to apply one-way from a single memory target, are also
> transferrable to other memory targets when there is a data dependency
> involved between them.

"Transferrable" is not the word I would use, nor does it describe the 
way you should think about this.

This is just an example of the fact that ordering is transitive.  So if:

	write A is ordered before write B (by an intervening UNLOCK-LOCK 
	pair), and

	write B is ordered before read C (because C reads from B and is
	on a different CPU), and

	read C is ordered before read D (by an address dependency), and

	read D is ordered before read E (because D happens to be a
	load-acquire)...

then of course A is ordered before E.

The exact nature of the individual orderings -- such as the fact that 
one of them is a dependency -- doesn't matter.  What matters is that in 
terms of the times when these operations execute, we have A < B < C < D 
< E.  Naturally this implies A < E.  As well as B < E, C < E, and so on.

As such, I don't think it's important to send much time on this in the 
documentation.  It should be pretty obvious.

The one thing to watch out for is the imprecision of the phrase "ordered 
before".  When writes are involved, the order in which the writes occur 
is not the only factor; you also have to consider the order in which 
those writes become visible to other CPUs.  In the example above, we 
know that the UNLOCK-LOCK pair causes write A to become visible to C's 
CPU before write B does.  Therefore, since write B definitely is visible 
to read C, it follows that any read on C's CPU that is ordered after C 
will observe write A.

Alan Stern