[PATCH] malloc: add locking to thread cache

[Mike Frysinger]

On 26 Jan 2016 13:40, Szabolcs Nagy wrote:
> 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.

and that has a real cost for real time code, as well as adding real
overhead to hot paths.  we spend so much time on trying to get lock
less code, just to re-add overhead by calling into the kernel ?

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

err, this statement makes no sense.  if you were writing portable
code, you wouldn't be using malloc or other non-as safe code in
the signal handler in the first place.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160126/95d36ed9/attachment.sig>