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: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Andrew Hunter <ahh at google dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 6 Dec 2013 15:37:11 -0500
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <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> <CADroS=7gw+zXDbaPR=bnR7hSe2yxBYgi6Ao14pwa03=Ra-t=7A at mail dot gmail dot com> <orvbz1n8vq dot fsf at livre dot home>
On Fri, Dec 06, 2013 at 04:15:37PM -0200, Alexandre Oliva wrote:
> On Dec 5, 2013, Andrew Hunter <ahh@google.com> wrote:
>
> > On Thu, Nov 28, 2013 at 5:03 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
>
> >> The lock is recursive, but I don't see anything in the patch besides
> >> the CAS loops that avoids inconsistent state, particularly in the
> >> case of lazy TLS relocation (introduced with GNU2 TLS). Was that not
> >> taken into account?
>
> > glibc recursive locks aren't async-signal-safe. We avoid problems
> > with reentrancy via dl_mask_all_signals.
>
> But that doesn't avoid *concurrency* problems, does it?
>
> Besides, GNU2 TLS provides for lazy TLS relocation (as mentioned above),
> and that most certainly takes the DL lock. I don't see anything in the
> patch that would avoid signal-safety problems in that path.
I would propose just preallocating the descriptors at dlopen time...
Rich