[PATCH v2] malloc: Fix tcache leak on thread destruction [BZ #22111]

Carlos O'Donell carlos@redhat.com
Fri Oct 6 16:35:00 GMT 2017


On 10/02/2017 06:43 PM, Andrew Pinski wrote:
> On Mon, Oct 2, 2017 at 6:36 PM, DJ Delorie <dj@redhat.com> wrote:
>>
>> Carlos O'Donell <carlos@systemhalted.org> writes:
>>> diff --git a/malloc/tst-malloc-tcache-leak.c b/malloc/tst-malloc-tcache-leak.c
>>> +void *
>>> +worker (void *data)
>>> +{
>>> +  /* Allocate an arbitrary amount of memory that is known to fit into
>>> +     the thread local cache (tcache).  If we have at least 64 bins
>>> +     (default e.g. TCACHE_MAX_BINS) we should be able to allocate 32
>>> +     bytes and force malloc to fill the tcache.  We have the allocated
>>> +     memory escape back to the parent to be freed to avoid any compiler
>>> +     optimizations.  */
>>> +  return (void *) xmalloc (32);
>>> +}
>>
>> This would be slightly more future-proof if it did an alloc/free/alloc
>> cycle, in case in the future malloc doesn't init the tcache "just
>> because".  The free would force the init, since the chunk would be
>> stored in the tcache.
>>
>> Actually, a malloc/free might be a better test, since it tests that the
>> free'd chunks in the tcache are freed as well as the tcache
>> infrastructure itself.  Or maybe as a second test.
> 
> And if you are going to do a malloc/free pair, make sure you add a
> compiler barrier in the code so the compiler does not delete the
> malloc/free pairs (which it does already).

Thanks DJ, that's a good idea about alloc/free/alloc.
Andrew, Yup, compiler barrier `__asm__ volatile ("" ::: "memory");`

v3 patch attached.

How does this look?

Signed-off-by: Carlos O'Donell <carlos@redhat.com>

Would appreciate any Reviewed-by entries from either of you.

-- 
Cheers,
Carlos.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-malloc-Fix-tcache-leak-after-thread-destruction-BZ-2.patch
Type: text/x-patch
Size: 8276 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20171006/1d7e40cf/attachment.bin>


More information about the Libc-alpha mailing list