[PATCH] malloc: add locking to thread cache

Szabolcs Nagy szabolcs.nagy@arm.com
Tue Jan 26 13:40:00 GMT 2016


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
>>
>>
>>
> 



More information about the Libc-alpha mailing list