This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should glibc be fully reentrant? -- No. (Roland was right).

On 12/21/2014 03:42 PM, OndÅej BÃlka wrote:
> On Mon, Dec 15, 2014 at 09:52:52AM +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, and some actually aren't in practice.
> You do not have to create perfect solution, most programmers would not 
> care if we provided reentrancy on all architectures but sparc.
> A malloc example that I wrote earlier is not perfect but would solve most 
> reports in bugzilla and would be enough in cases where it was infinite
> recursion without signal.

Oh, sorry, the thing isâhow do you write a useful malloc in C if you
cannot use atomic instructions because their behavior for valid uses of
malloc is unspecified?

It's not useful to say we support malloc hooking, but at the same time
impose requirements which implementations cannot match (in addition to
âyou must not define memalign because it is out of the implementation
namespaceâ vs âyou must define memalign to make sure that you can free
the pointers it returnsâ).

Florian Weimer / Red Hat Product Security

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]