This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should glibc be fully reentrant? -- No. (Roland was right).
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Fri, 30 Jan 2015 14:56:43 +0100
- Subject: Re: Should glibc be fully reentrant? -- No. (Roland was right).
- Authentication-results: sourceware.org; auth=none
- References: <5488F9C6 dot 9080605 at redhat dot com> <54898FE0 dot 8060701 at redhat dot com> <20141211133353 dot GB10717 at domone> <5489A11A dot 3080300 at redhat dot com> <20141211141136 dot GA17090 at domone> <548ABA5B dot 9090002 at redhat dot com> <20141212161750 dot GA22945 at domone> <548EA164 dot 5040004 at redhat dot com> <1418639895 dot 25818 dot 23 dot camel at triegel dot csb>
On 12/15/2014 11:38 AM, Torvald Riegel wrote:
> On Mon, 2014-12-15 at 09:52 +0100, Florian Weimer wrote:
>> On 12/12/2014 05:17 PM, OndÅej BÃlka wrote:
>>> On Fri, Dec 12, 2014 at 10:50:19AM +0100, Florian Weimer wrote:
>>>> On 12/11/2014 03:11 PM, OndÅej BÃlka wrote:
>>>>
>>>>> Yes, I wrote that from head so I forgot volatile/asm barrier. One could
>>>>> add requirement like needs to be compiled by gcc4-6+ instead pure C as
>>>>> just using signals is not part of C standard.
>>>>
>>>> GCC emulates atomics with locks on some platforms, or some lock-free
>>>> instruction sequences may not be reentrant. This begins to look
>>>> like a can of worms, unfortunately.
>>>>
>>> It uses only thread local variable. If they are not reentrant its
>>> gigantic hole, you could not for example use sigaction as it could
>>> set errno which is thread local variable.
>>
>> Sorry, what I'm trying to say is that atomics are not specified as
>> async-signal-safe
>
> That's not correct in general. My TLDR reply would be that all atomic
> operations that claim to be lock-free are also async-signal-safe (see
> GCC's __atomic_always_lock_free and the related C11/C++11 functions).
That's not what C11 says. I have reviewed this area of the standard
several times, and I do believe it's unspecified in the sense that the
standard intends to say something about it, but doesn't actually do so.
> Using this rule of thumb would allow us to assume atomics to be
> async-signal-safe in glibc.
>
> Outside of glibc, I agree that some atomics (notably those not claiming
> to be lock-free) to be actually not async-signal safe.
Okay, that makes sense.
--
Florian Weimer / Red Hat Product Security