From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13756 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alexey Izbyshev Newsgroups: gmane.linux.lib.musl.general Subject: Re: __synccall: deadlock and reliance on racy /proc/self/task Date: Mon, 11 Feb 2019 00:04:06 +0300 Message-ID: <8e5fe0aa993c35c4c92605d455096f66@ispras.ru> References: <1cc54dbe2e4832d804184f33cda0bdd1@ispras.ru> <20190207183626.GQ23599@brightrain.aerifal.cx> <20190208183357.GX23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="76182"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Roundcube Webmail/1.1.2 Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-13772-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 10 22:04:20 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gswGy-000Jj5-HC for gllmg-musl@m.gmane.org; Sun, 10 Feb 2019 22:04:20 +0100 Original-Received: (qmail 30168 invoked by uid 550); 10 Feb 2019 21:04:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30149 invoked from network); 10 Feb 2019 21:04:17 -0000 In-Reply-To: <20190208183357.GX23599@brightrain.aerifal.cx> X-Sender: izbyshev@ispras.ru Xref: news.gmane.org gmane.linux.lib.musl.general:13756 Archived-At: 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. Alexey