mmap'ed robust mutexes and possible undefined behaviour

Carlos O'Donell carlos@systemhalted.org
Wed Nov 26 19:16:00 GMT 2014


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.



More information about the Libc-help mailing list