From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12239 invoked by alias); 2 Sep 2014 10:14:36 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 12207 invoked by uid 48); 2 Sep 2014 10:14:32 -0000 From: "bernie.ogden at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug nptl/17337] New: [sh] Invalid futex demotion in __lll_timedlock Date: Tue, 02 Sep 2014 10:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bernie.ogden at linaro dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg00002.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17337 Bug ID: 17337 Summary: [sh] Invalid futex demotion in __lll_timedlock Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: nptl Assignee: unassigned at sourceware dot org Reporter: bernie.ogden at linaro dot org CC: drepper.fsp at gmail dot com This issue has been fixed for all affected platforms other than sh - see BZ16892. sh is left because it relies on an assembly implementation. Could be fixed by fixing the assembly implementation, or by moving to the Linux-generic lowlevellock.h. For the record, the issue is: (Analysis by Carlos O'Donell) sh/sh4 has an implementation of __lll_timedlock that sets futex to 1 without first checking that it is 0. This allows the futex to move from 2 (locked with waiters) to 1 (locked with no waiters) on these platforms. This does not create a correctness problem, but it does create a pair of performance problems. 1) Up to N threads can fail to sleep when they ought to have done, where N is the number of threads expecting futex==2. For example: * T1 calls __lll_timedlock setting futex to 1 and taking the lock. * T2 calls __lll_timedlock setting futex to 1 but does not take the lock. * T2 calls __lll_timedlock_wait and sets the futex to 2 and does not gain the lock. * T3 calls __lll_timedlock setting futex to 1 but does not take the lock. * T2 calls lll_futex_time_wait but fails with -EWOULDBLOCK because T3 reset futex to 1. -> One inflight thread (T2), and one spurious failed futex wait syscall. * T2 again sets the futex to 2 and does not gain the lock. * ... T2 and T3 go on to call futex wait syscall and both sleep. 2) __lll_unlock only wakes if futex was > 1 prior to release. Thus it can happen that __lll_timedlock keeps setting futex from 2 to 1 just prior to __lll_unlock calls, preventing waiters from being awoken. This certainly affects m68k, arm and aarch64 - sh may also be affected but it's a little harder to tell as its written in asm. In both cases, the solution is simply to do an atomic_compare_and_exchange_acq (as the unaffected platforms already do), rather than an atomic_exchange_acq, so that __lll_timedlock does not change futex from 2 to 1. -- You are receiving this mail because: You are on the CC list for the bug.