[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