This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: mmap'ed robust mutexes and possible undefined behaviour
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Marcos Dione <mdione at grulic dot org dot ar>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, "Carlos O'Donell" <carlos at redhat dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Wed, 26 Nov 2014 14:16:02 -0500
- 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> <20141125205649 dot GE3759 at diablo dot grulicueva dot local>
On Tue, Nov 25, 2014 at 3:56 PM, Marcos Dione <mdione@grulic.org.ar> wrote:
> 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.Â
I don't object to someone implementing this in glibc, but I bet it
will require coordination with the kernel to get right.
Cheers,
Carlos.