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

[Frederic Weisbecker]

Le Fri, Sep 11, 2026 at 03:05:47PM -0400, Alan Stern a écrit :
> 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.

Right, transitive fits much better here.

> 
> 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.

Ok

> 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.

Right, heh, terminology indeed matters here more than anywhere :-)

Thanks for all the explanations!

-- 
Frederic Weisbecker
SUSE Labs