[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access

["triegel at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13690

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
                 CC|                            |triegel at redhat dot com

--- Comment #24 from Torvald Riegel <triegel at redhat dot com> ---
I agree that after release of a mutex (i.e., atomic_exchange_rel (__futex, 0)),
we have both (1) a pending load from mutex->__data.__kind and (2) a pending
futex_wake call.

However, I think it is an open question whether POSIX actually allows
destruction of the mutex just based on having obtained ownership of the lock. 
The example given in the standard and reproduced in Comment #1 is in an
informative section, and it conflicts with a statement in the normative
section: "Attempting to destroy a locked mutex or a mutex that is referenced
[...] by another thread results in undefined behavior."

Arguably, a mutex could still be considered "referenced" as long as a call to
mutex_unlock has not yet returned.  This would make the example in the
normative text incorrect.  OTOH, the intended semantics could also be that if a
program ensures that (1) a thread is the last one to lock a mutex, and (2) this
thread is able to lock and unlock a mutex, then this thread is also allowed to
destroy the mutex; IOW, being able to doing the last lock and unlock of the
mutex could be the defining constraint for when destruction is allowed.

(That is what C++11 seems to require based on a quick read.  C11 isn't very
verbose but requires just that no thread is blocked on the mutex when it is
destructed; nonetheless, it also mentions that all resources of the mutex are
claimed, which could be understood to mean the same as the "referenced"
constraint in POSIX.)

I've asked the Austin Group for clarification:
http://austingroupbugs.net/view.php?id=811
Depending on how they decide, this is either not a bug, or we'll have to avoid
the pending load and futex_wake call, or make them harmless.  The proposed
patch should be right for the pending load, but the futex_wake needs more
investigation: A futex_wake to a futex without waiters (or even to a futex not
mapped anymore) should be harmless, but it could be different with PI futexes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.