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 redhat dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Marcos Dione <mdione at grulic dot org dot ar>, libc-help at sourceware dot org
- Date: Tue, 25 Nov 2014 17:07:54 -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>
On 11/25/2014 02:26 PM, 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.
How do you make the mutex enter inconsistent state? Would that require
scanning robust lists when the mappings are to be removed? That seems
like a big performance loss on the hot path for an unlikely case?
Cheers,
Carlos.