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: Rich Felker <dalias at aerifal dot cx>
- To: Andrew Hunter <ahh at google dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 23 Sep 2013 23:53:37 -0400
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <523F2ED8 dot 8090909 at redhat dot com> <1379977289-21260-1-git-send-email-ahh at google dot com> <20130924025738 dot GK20515 at brightrain dot aerifal dot cx> <CADroS=6nObHGZR3xpC3-seq1Q1GYddmZF=iUOznmAB4vStjs-Q at mail dot gmail dot com> <20130924033442 dot GL20515 at brightrain dot aerifal dot cx> <CADroS=4AH3vo=QHDGdCDqEBU3HXEQZM0PgfX6m0MHt+tn7xtbw at mail dot gmail dot com>
On Mon, Sep 23, 2013 at 08:39:21PM -0700, Andrew Hunter wrote:
> OK, great. I can do that. Are these namespaces documented somewhere?
Yes. ISO/IEC 9899, 1999 or 2001 edition, 7.1.3 Reserved Identifiers.
Rich
> On Sep 23, 2013 8:34 PM, "Rich Felker" <dalias@aerifal.cx> wrote:
>
> > On Mon, Sep 23, 2013 at 08:27:46PM -0700, Andrew Hunter wrote:
> > > What names would you like me to use?
> >
> > Anything in the namespace reserved for the implementation, such as
> > __signal_safe_malloc, etc.
> >
> > Rich
> >
> >
> > > On Sep 23, 2013 7:57 PM, "Rich Felker" <dalias@aerifal.cx> wrote:
> > >
> > > > On Mon, Sep 23, 2013 at 04:01:29PM -0700, Andrew Hunter wrote:
> > > > > TLS accesses from initial-exec variables are async-signal-safe. Even
> > > > > dynamic-type accesses from shared objects loaded by ld.so at startup
> > > > > are. But dynamic accesses from dlopen()ed objects are not, which
> > > > > means a lot of trouble for any sort of per-thread state we want to
> > > > > use from signal handlers since we can't rely on always having
> > > > > initial-exec. Make all TLS access always signal safe.
> > > > >
> > > > > Doing this has a few components to it:
> > > > >
> > > > > * We introduce a set of symbols
> > symbol_safe_{malloc,free,memalign,&c}.
> > > > > They do what it says on the box, but guarantee
> > async-signal-safety.
> > > > > We provide a minimal mmap-based implementation in ld.so; anyone
> > can
> > > > > override them more efficiently. (This may prove useful
> > elsewhere.)
> > > > > [...]
> > > > >
> > > > > # Pointer protection.
> > > > > __pointer_chk_guard;
> > > > > +
> > > > > + # for signal safe TLS
> > > > > + signal_safe_malloc; signal_safe_free; signal_safe_memalign;
> > > > > + signal_safe_realloc; signal_safe_calloc;
> > > >
> > > > These symbol names are not acceptable; they are in the space of names
> > > > reserved for the application, and since you're allowing them to be
> > > > overridden, a conforming application can cause horrible mayhem by
> > > > happening to use the same names for a different purpose. (In the worst
> > > > case, imagine an application defining signal_safe_malloc in a way that
> > > > uses TLS, such that signal_safe_malloc and __tls_get_addr become
> > > > mutually recursive...)
> > > >
> > > > Rich
> > > >
> >