[Bug nptl/17337] New: [sh] Invalid futex demotion in __lll_timedlock

["bernie.ogden at linaro dot org" <sourceware-bugzilla@sourceware.org>]

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.