This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/17337] New: [sh] Invalid futex demotion in __lll_timedlock
- From: "bernie.ogden at linaro dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 02 Sep 2014 10:14:30 +0000
- Subject: [Bug nptl/17337] New: [sh] Invalid futex demotion in __lll_timedlock
- Auto-submitted: auto-generated
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.