|
Message-ID: <8e5fe0aa993c35c4c92605d455096f66@ispras.ru> 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.