This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: add locking to thread cache
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>, Florian Weimer <fweimer at redhat dot com>, Joern Engel <joern at purestorage dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, <nd at arm dot com>
- Date: Tue, 26 Jan 2016 13:40:10 +0000
- Subject: Re: [PATCH] malloc: add locking to thread cache
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com> <1453767942-19369-52-git-send-email-joern at purestorage dot com> <56A76A49 dot 8010804 at arm dot com> <56A77149 dot 1090204 at redhat dot com> <56A77356 dot 9070503 at samsung dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 26/01/16 13:23, Yury Gribov wrote:
> On 01/26/2016 04:14 PM, Florian Weimer wrote:
>> On 01/26/2016 01:44 PM, Szabolcs Nagy wrote:
>>> On 26/01/16 00:25, Joern Engel wrote:
>>>> With signals we can reenter the thread-cache. Protect against that with
>>>> a lock. Will almost never happen in practice, it took the company five
>>>> years to reproduce a similar race in the existing malloc. But easy to
>>>> trigger with a targeted test.
>>>
>>> why do you try to make malloc as-safe?
>>>
>>> isn't it better to fix malloc usage in signal handlers?
>>
>> We have functionality like dprintf, syslog, backtrace, C++ thread-local
>> object access which might be used from signal handlers, but which can
>> call malloc.
>
> Right. One can argue that this is an error and someone should go fix the code but in my experience most
> real-world signal handlers have these problems and noone is going to rewrite them any time soon.
>
it is easy to write non-conforming code, but that
does not mean the libc should try to make it work.
in this case signals should be blocked whenever the
library is entered through non-as-safe api calls.
that has a significant cost for portable code.
>> Fixing this in malloc may seem attractive, but I doubt it
>> can be made completely reliable by concentrating changes there.
>>
>> Florian
>>
>>
>>
>