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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: Andrew Hunter <ahh at google dot com>, Rich Felker <dalias at aerifal dot cx>, GNU C Library <libc-alpha at sourceware dot org>, <allan at archlinux dot org>, Carlos O'Donell <carlos at redhat dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Date: Thu, 9 Jan 2014 16:42:01 +0000
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <52C4DC54 dot 4000109 at redhat dot com> <1388689454-1854-1-git-send-email-ahh at google dot com> <CALoOobPio5625ws7dSWepgQbKmqHifvbU3tKWtKFS-tz_zihdQ at mail dot gmail dot com> <CADroS=7BBPbJ5bAUUy5VUWHX+gCrRmrEk17qO-s9zkdVNeFbxA at mail dot gmail dot com> <20140103074522 dot GT24286 at brightrain dot aerifal dot cx> <CADroS=49b8c8KCiNF2cHHRk5nPmy8LzYYF_x=GZfOCCQORkx8A at mail dot gmail dot com> <CALoOobNz=FzbSkJdPMFwqnFdpyNcAy8vDDEftj+vbMT5r8mJAw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401081752130 dot 1349 at digraph dot polyomino dot org dot uk> <CALoOobM6R+ua_0ffxRdaS_h69oUJ_+CoidxvLi+U_tdvJZY3dg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401082122230 dot 8625 at digraph dot polyomino dot org dot uk> <CALoOobMWsgbAjupv7Cj0-Xz0ND+TNinj26TquvEwZXM+BjfgiA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401090233380 dot 8625 at digraph dot polyomino dot org dot uk> <CALoOobOHjd+8guXBEsHuO=FtiPFRED4Zb=qDdTvEHr=01nRwHg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401091544010 dot 21172 at digraph dot polyomino dot org dot uk> <52CEC6DD dot 9010800 at google dot com>
On Thu, 9 Jan 2014, Paul Pluzhnikov wrote:
> What about the race I posited as possible explanation? Do you agree that there
> is a race? Does sleep(1) before dlclose() "fix" it?
I agree there is a race, and the sleep does fix it (of course it also
makes the test very slow).
Maybe have the signal handler outside the loaded module call the function
from the loaded module, but with sem_post in the function outside the
module? I haven't tested whether this fixes the powerpc problem, but it
should avoid the identified race with the module being dlclosed while code
from it is executing. (There would of course then be the need to have
memory barriers to ensure the current pointer obtained from dlsym is
available from the thread calling the signal handler - and it would be
necessary to ensure that the test does still show up the non-signal-safety
if run with older glibc.)
> Also, is the crash you are seeing intermittent (how frequent?) or reliable?
The crash is reliable.
--
Joseph S. Myers
joseph@codesourcery.com