mmap'ed robust mutexes and possible undefined behaviour
Wed Nov 26 19:16:00 GMT 2014
On Tue, Nov 25, 2014 at 3:56 PM, Marcos Dione <firstname.lastname@example.org> 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:
> «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.
More information about the Libc-help