This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Ian Lance Taylor <iant at google dot com>, Roland McGrath <roland at hack dot frob dot com>, Richard Henderson <rth at twiddle dot net>, libc-alpha at sourceware dot org, Andrew Hunter <ahh at google dot com>
- Date: Fri, 20 Sep 2013 13:24:09 -0400
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <20120612193224 dot 8E43619060E at elbrus2 dot mtv dot corp dot google dot com> <4FD8D974 dot 7090903 at twiddle dot net> <20120613182826 dot 0CFAB2C0A3 at topped-with-meat dot com> <CALoOobMtXCw+oe7ZL0=my8YH5st8b1==CasS8i07z6G9DfaX-w at mail dot gmail dot com> <20120613210444 dot 659732C095 at topped-with-meat dot com> <mcr4nqebzok dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <20120614002931 dot ABB762C08B at topped-with-meat dot com> <mcr1uliaeep dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <CALoOobPJ7G7ciRfc2JwzHjsDTg4-_h-SXqeU1zR4WEzoyQhyNg at mail dot gmail dot com> <or8uyr372c dot fsf at livre dot home>
On 09/20/2013 10:23 AM, Alexandre Oliva wrote:
> On Sep 18, 2013, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
>
>> - introduces async-signal-safe mmap-based allocator into elf/dl-misc.c, and
>> - updates the rest of the loader to use this allocator when getting space
>> for non-static TLS.
>
> Why not make malloc AS-safe instead? I've reviewed it, and having
> multiple arenas seems to make it not too hard to use an alternate arena
> if the primary arena for a thread happens to be already locked. It's
> only if we have to create a new arena that we might get in trouble, but
> then, worst case, malloc itself can always fallback to mmapped
> allocation.
>
> Wouldn't that be a more advantageous path to take?
Yes and no.
It would be advantageous in that having access to malloc from a signal
handler is another useful function you can use.
The disadvantage is that you now have to maintain malloc AS-safe
forever and auditing that much code is difficult from a maintenance
perspective. In addition to that it's a non-portable use of malloc
that impacts portability.
It would be easier to audit a smaller and simpler allocator that
can be used exclusively for TLS allocations from within the
dynamic loader.
Therefore I would not attempt to pursue making malloc AS-safe
as it may inhibit optimizations we may want to make in the future.
Cheers,
Carlos.