This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>, OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Andrew Hunter <ahh at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 28 Nov 2013 23:26:03 -0500
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1310222145490 dot 13258 at digraph dot polyomino dot org dot uk> <CALoOobMsO6X86JFD4J7F-EL-J+xOTEOVbzH=6mwrvfCnFvw57Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1311052233090 dot 30260 at digraph dot polyomino dot org dot uk> <CALoOobM70-mix+=1zuDnSoK7SRqQChbL=03xBkUcFf1fyS1Mjw at mail dot gmail dot com> <CALoOobP7kdpZCZA0a7MZWCtONu81fW4H_qAWOEfpfvzxJgG_=Q at mail dot gmail dot com> <CALoOobP6rTDosadvLKhHY+deDsU-FtvyO8QX_Y4dZy716e2ATQ at mail dot gmail dot com> <CALoOobOCT-inwMZkzEr+JYT4c8qwpN-EGMPFu_kHQTpc2icj0g at mail dot gmail dot com> <CALoOobPHo7+jG0nfiZp9afC2rArLUMRYZEag21W+78UBTZF=CQ at mail dot gmail dot com> <orvbzckoif dot fsf at livre dot home> <20131129035506 dot GA20469 at domone dot podge> <20131129040117 dot GZ24286 at brightrain dot aerifal dot cx>
On 11/28/2013 11:01 PM, Rich Felker wrote:
> On Fri, Nov 29, 2013 at 04:55:48AM +0100, OndÅej BÃlka wrote:
>> A proper solution would be make generic malloc async-signal safe. It is
>> question of what is acceptable overhead. I can make a wrapper over any
>> allocator that does that at cost of two tls access. You would pay a mmap
>> overhead only when you are in signal where we do not care about
>> effectivity.
>
> Not a solution as long as glibc officially supports applications
> replacing malloc.
The loader could access the implementation's malloc via GLIBC_PRIVATE
symbols.
I'm against this because any sufficiently complex and performant
implementation of malloc will be difficult to audit for AS-safety.
In the end AS-safety may even limit your flexibility, but I don't
discount the possibility of writing the allocator such that it performs
well.
A small signal-safe allocator as proposed by Google is the easiest way
to get the job done. We can always fix this later.
Cheers,
Carlos.