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: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, 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: Fri, 29 Nov 2013 13:29:49 +0100
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <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> <5298175B dot 8090604 at redhat dot com>
On Thu, Nov 28, 2013 at 11:26:03PM -0500, Carlos O'Donell wrote:
> 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.
>
Third party issue, signal safety is beyond of what is mandated by
standards and on best effort. Ask a custom allocator to implement signal
safety or use appropriate wrapper.
> The loader could access the implementation's malloc via GLIBC_PRIVATE
> symbols.
>
or different name than malloc, or creating interceptor library that has
priority over user allocator by prepending it to LD_PRELOAD in linker or
...
> I'm against this because any sufficiently complex and performant
> implementation of malloc will be difficult to audit for AS-safety.
>
What I send is a wrapper, it is irrelevant how complex and convoluted
allocator is, it just suffices to check that wrapper correctly
intercepts calls and detect signal behaviour.
> 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.
>
Not on x86, I did a benchmark to see how big is overhead, after
eliminating sources of noise a signal safe variant is pretty
indistingushible from normal. There were two preventable slowdowns,
first was that dynamic tls is access slower so we need to use static tls.
Second was caused by gcc which emmited storing five registers at start
of free for unlikely code for returning memory that is suppressed by
appropriate expect.
> A small signal-safe allocator as proposed by Google is the easiest way
> to get the job done. We can always fix this later.
>
We are talking about two separate changes. One is replacing locks by
atoimics, second is using safe allocator. There are several
possibilities how implement allocator, so we should move discussion to
separate thread.