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

[Ondřej Bílka]

On Tue, Jul 14, 2015 at 10:21:13PM +0200, Torvald Riegel wrote:
> 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.
>

So this is equivalent of my patch from 2013 where you said that you need
to ask posix with fixed bitrot?