[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Feb 2019 00:04:06 +0300
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
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
<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
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.
