Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Feb 2019 00:04:06 +0300
From: Alexey Izbyshev <>
To: Rich Felker <>
Subject: Re: __synccall: deadlock and reliance on racy /proc/self/task

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


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.