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

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

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #5 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #3)
> 1. Thread A unlocks the process-shared, robust mutex and is preempted after
> the mutex is removed from the robust list and atomically unlocked, but
> before it's removed from the list_op_pending field of the robust list header.
> 
> 2. Thread B locks the mutex, and, knowing by program logic that it's the
> last user of the mutex, unlocks and unmaps it, allocates/maps something else
> that gets assigned the same address as the shared mutex mapping, and then
> exits.

Isn't this undefined behaviour? You have not specified how you established a
happens-after relationship between the destruction of the mutex by Thread B and
the last use by Thread A. In this description you give it would seem to me that
Thread A is still not done, and that the "program logic" from Thread B is
destroying an in-use mutex and that results in undefined behaviour from Thread
A. Thread B fails to establish a happens-after the use of the mutex from Thread
A. If Thread B truly establishes a happens-after the unlock from Thread A, is
there a problem? I don't think there is.

Did I get something wrong Rich?

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