Should glibc be fully reentrant? -- No. (Roland was right).
Florian Weimer
fweimer@redhat.com
Thu Dec 11 13:50:00 GMT 2014
On 12/11/2014 02:33 PM, OndÅej BÃlka wrote:
> On Thu, Dec 11, 2014 at 01:36:48PM +0100, Florian Weimer wrote:
>> On 12/11/2014 02:56 AM, Carlos O'Donell wrote:
>>> After serious review it seems like we will need to start by
>>> saying that an interposed malloc must operate as-if it were
>>> in async-signal context and use only those functions which
>>> are marked as async-signal-safe.
>>
>> Practically speaking, this seems rather restrictive. Most mallocs
>> need locking, and implementations may want to use pthread mutexes.
>> Those are not async-signal-safe, and I doubt they can be made
>> reentrant, either.
>>
> No, making them reentrant is relatively simple as I wrote before, just
> wrap calls in something
>
> static __thread int recursed
> if (recursed)
> return allocate_by_mmap();
> else
> {
> recursed=1;
> normal;
> recursed=0;
> }
I meant the locking functions.
Anyway, the above needs a volatile specifier somewhere, and even then,
it might still be outside of what can be expressed in C.
--
Florian Weimer / Red Hat Product Security
More information about the Libc-alpha
mailing list