This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mmap'ed robust mutexes and possible undefined behaviour

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:

    «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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]