[Bug nptl/14485] File corruption race condition in robust mutex unlocking

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

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

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
In reply to comment 4, this issue can be avoided by applications in at least
two ways:

1. Use a separate mapping of the shared synchronization object for each
user/thread that might want to unmap it.

2. Use a separate synchronization object local to the process to synchronize
unmapping of the shared mutex.

Since the only way you'd have multiple threads in the same process accessing
the shared synchronization object is by storing the pointer to the (mapping
containing the) shared mutex in some process-local object that's shared between
threads, it seems natural that you would already be synchronizing access to
this memory with another mutex (or other synchronization object) stored with
the pointer. So approach 2 seems like it's always practical, probably doesn't
involve any new synchronization, and likely makes it unnecessary/useless to
support self-synchronized unmapping. On the other hand, it may not actually be
any harder to support self-synchronized unmapping than to support
self-synchronized destruction+unmapping, which almost certainly needs to be
supported.

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