mmap'ed robust mutexes and possible undefined behaviour

[Marcos Dione]

On Tue, Nov 25, 2014 at 08:26:33PM +0100, Florian Weimer wrote:
> * Florian Weimer:
> 
> > * Carlos O'Donell:
> >
> >>> 1. we open a file.
> >>> 2. we mmap it and use that mem to store a robust mutex.
> >>> 3. we lock the mutex.
> >>> 4. we munmap the file.
> >>> 5. we close the file.
> >>
> >> Undefined behaviour.
> >>
> >> This results in undefined behaviour since the allocated storage for
> >> the mutex object has been lost. You need to keep that storage around
> >> for the robust algorithms to work with. Without any data you can't
> >> do anything.
> >
> > Some might expect that the mutex enters inconsistent state when the
> > mutex is unmapped, not just on process death.  Then the data would
> > still be available at the time the state change would need to happen.
> 
> Ugh.  I should have said that this would be an extension, it's not
> required by POSIX.

    yeah, like Solaris' non portable version:

http://docs.oracle.com/cd/E19253-01/816-5168/pthread-mutexattr-setrobust-np-3c/index.html

    «When the owner of a mutex with the PTHREAD_MUTEX_ROBUST_NP
robustness attribute dies, or when the process containing such a locked
mutex unmaps the memory containing the mutex or performs one of the
exec(2) functions, the mutex is unlocked.»

-- 
(Not so) Random fortune:
22:22 < m4rgin4l_> hendrix no tocaba la viola, violaba la toca