This is the mail archive of the
mailing list for the glibc project.
Re: mmap'ed robust mutexes and possible undefined behaviour
- From: Marcos Dione <mdione at grulic dot org dot ar>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Carlos O'Donell <carlos at redhat dot com>, libc-help at sourceware dot org
- Date: Tue, 25 Nov 2014 21:56:49 +0100
- Subject: Re: mmap'ed robust mutexes and possible undefined behaviour
- Authentication-results: sourceware.org; auth=none
- References: <20141124203441 dot GA3759 at diablo dot grulicueva dot local> <5473A7B0 dot 5050803 at redhat dot com> <87sih7t74c dot fsf at mid dot deneb dot enyo dot de> <87oarvt72u dot fsf at mid dot deneb dot enyo dot de>
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