This is the mail archive of the
mailing list for the glibc project.
Re: mmap'ed robust mutexes and possible undefined behaviour
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Marcos Dione <mdione at grulic dot org dot ar>, libc-help at sourceware dot org
- Date: Tue, 25 Nov 2014 20:26:33 +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>
* 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.