Re: __synccall: deadlock and reliance on racy /proc/self/task

[Alexey Izbyshev <izbyshev@ispras.ru>]

On 2019-02-08 21:33, Rich Felker wrote:
> On Fri, Feb 08, 2019 at 09:14:48PM +0300, Alexey Izbyshev wrote:
>> ...I was talking about a barrier
>> between loads of head and cp->tid/cp->next:
>> 
>> for (cp = head; cp && cp->tid != tid; cp=cp->next);
>> 
>> In my understanding, we need consume semantics to observe correct
>> values of tid and next after we load head. If we don't take Alpha
>> into account,
>> it probably works without barriers on most current architectures,
>> however, I don't know what policy musl has for such cases.
> 
> I don't see how that's the case. The only stores to members of ch are
> made before the a_cas_p (which has seq_cst order, but just release
> would suffice) storing &ch into head and making it visible.
> 
This is probably off-topic because we know that the issue is not related 
to barriers, but I was referring to what is described in DATA DEPENDENCY 
BARRIERS section at 
<https://www.kernel.org/doc/Documentation/memory-barriers.txt>. Since 
the last time I looked at it, kernel devs marked it "historical" and 
added the following note:

> As of v4.15 of the Linux kernel, an smp_read_barrier_depends() was
> added to READ_ONCE(), which means that about the only people who
> need to pay attention to this section are those working on DEC Alpha
> architecture-specific code and those working on READ_ONCE() itself.
> For those who need it, and for those who are interested in the history,
> here is the story of data-dependency barriers.

So musl probably has no need to care.

Alexey