From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1290 invoked by alias); 18 Dec 2013 20:43:11 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 1273 invoked by uid 89); 18 Dec 2013 20:43:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2013 20:43:10 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBIKgZts000420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Dec 2013 15:42:35 -0500 Received: from [10.36.7.73] (vpn1-7-73.ams2.redhat.com [10.36.7.73]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBIKgXPv011378; Wed, 18 Dec 2013 15:42:33 -0500 Subject: Re: [RFC][BZ #13690] Always read private before lll_unlock. From: Torvald Riegel To: =?UTF-8?Q?Ond=C5=99ej_B=C3=ADlka?= Cc: Atsushi Nemoto , libc-alpha@sourceware.org, libc-ports@sourceware.org In-Reply-To: <20131206194305.GA26401@domone.podge> References: <20131206190159.GA25502@domone.podge> <20131206194305.GA26401@domone.podge> Content-Type: text/plain; charset="UTF-8" Date: Wed, 18 Dec 2013 20:43:00 -0000 Message-ID: <1387399352.23049.11823.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00029.txt.bz2 On Fri, 2013-12-06 at 20:43 +0100, Ondřej Bílka wrote: > On Fri, Dec 06, 2013 at 08:01:59PM +0100, Ondřej Bílka wrote: > > Hi, a related issue to semaphore races is a race in mutex unlocking. > > > from bugzilla: > > > > On most platforms, lll_unlock() is defined as a macro like this: > > #define lll_unlock(lock, private) \ > > ((void) ({ \ > > int *__futex = &(lock); \ > > int __val = atomic_exchange_rel (__futex, 0); \ > > if (__builtin_expect (__val > 1, 0)) \ > > lll_futex_wake (__futex, 1, private); \ > > })) > > > Which causes this problem that could be avoided by changing macro to > > #define lll_unlock(lock, private) \ > ((void) ({ \ > int *__futex = &(lock); \ > int __private = private \ > > I wrote a prelimitary patch for that, most of lll_unlock macros are > duplicates so I added a file include/futex_unlock.h with common > implementation. We should check these for more duplicates and if > other functions need similar wrapper. > > Comments? This needs clarification in POSIX; see my comment on #13690 (https://sourceware.org/bugzilla/show_bug.cgi?id=13690#c24). Depending on how the Austin Group decides, this is either not a bug, or we have to fix the pending load AND investigate whether the pending futex_wake call is harmless. The latter might be the case for normal mutexes, but I wouldn't be surprised to find out that PI or robust mutexes aren't as simple and need a more complex fix. Therefore, I think we should wait for the POSIX clarification and then decide what the next steps should be.