[PATCH][BZ 13690] Do not violate mutex destruction requirements.

[Torvald Riegel]

POSIX and C++11 require that a thread can destroy a mutex if no thread
owns the mutex, is blocked on the mutex, or will try to acquire it in
the future.  After destroying the mutex, it can reuse or unmap the
underlying memory.  Thus, we must not access a mutex' memory after
releasing it.  Currently, we can load the private flag after releasing
the mutex, which is fixed by this patch.

See https://sourceware.org/bugzilla/show_bug.cgi?id=13690 for more
background.
    
We need to call futex_wake on the lock after releasing it, however.
This is by design, and can lead to spurious wake-ups on unrelated futex
words (e.g., when the mutex memory is reused for another mutex).  This
behavior is documented in the glibc-internal futex API and in recent
drafts of the Linux kernel's futex documentation (see the draft_futex
branch of git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git).

Carlos, do you want to consider this for 2.22, or should this rather
target 2.23?  The actual change is simple.

Not tested.  Could someone test this on a non-x86-linux machine (I don't
have one handy).  Dave, could you test on sparc, please?


2015-07-14  Torvald Riegel  <triegel@redhat.com>

	[BZ #13690]
	* sysdeps/nptl/lowlevellock.h (__lll_unlock): Do not access the lock
	after releasing it.
	(__lll_robust_unlock): Likewise.
	* nptl/pthread_mutex_unlock.c (__pthread_mutex_unlock_full): Likewise.
	* sysdeps/unix/sysv/linux/sparc/lowlevellock.h (lll_unlock): Likewise.
	(lll_robust_unlock): Likewise.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mutex-destruction.patch
Type: text/x-patch
Size: 6242 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150714/dcf4d24f/attachment.bin>