[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #46 from Rich Felker <bugdal at aerifal dot cx> ---
I think I have a solution to the spurious-wakes problem using FUTEX_WAKE_OP.
The principle is simple: use an atomic compare-and-swap to release the lock, so
that we know before releasing (rather than immediately-after, as would be the
case with a plain swap) whether there are potentially waiters. Then there are
two cases:

1. Waiter count of zero and successful atomic CAS from owned/uncontended state
to zero: nothing else to do.

2. Waiter count nonzero or failed atomic CAS (meaning the state changed from
owned/uncontended to owned/contended): make a futex syscall with FUTEX_WAKE_OP
to perform the atomic unlock AFTER having locked the futex hash buckets, so
that a new waiter cannot arrive and thereby get a spurious wake.

This design is presently under discussion on the musl libc mailing list, in
this thread:

http://www.openwall.com/lists/musl/2014/08/08/12

One issue is that the FUTEX_WAKE_OP command takes two addresses, uaddr1 and
uaddr2, and performs a potentially expensive futex hash lookup on both. For our
purposes we do not need two different addresses, so I think if we pursue this
option, we should push the kernel folks to add a special case for
uaddr1==uaddr2 that optimizes out the second hash.

Thoughts?

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