This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should glibc be fully reentrant? What do we allow interposed symbols to do?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 23 Oct 2014 13:09:52 -0400
- Subject: Re: Should glibc be fully reentrant? What do we allow interposed symbols to do?
- Authentication-results: sourceware.org; auth=none
- References: <54456FA1 dot 9070804 at redhat dot com> <20141020204153 dot 83C542C3B0D at topped-with-meat dot com> <54457C4C dot 4080307 at redhat dot com> <20141021224739 dot 080382C3AB2 at topped-with-meat dot com> <54486800 dot 4040806 at redhat dot com> <CANu=Dmj-iO6uS8_PKgb=+TiyGau9_ijbJQjPYNFQqP-CKk+PqQ at mail dot gmail dot com> <54491354 dot 40507 at redhat dot com> <CANu=DmjZ5V_o6hpansTfH+OY_gRVfuRNB0EycuyMF-0-wVEY0A at mail dot gmail dot com>
On 10/23/2014 12:40 PM, Will Newton wrote:
> On 23 October 2014 15:40, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 10/23/2014 04:23 AM, Will Newton wrote:
>>> On 23 October 2014 03:29, Carlos O'Donell <carlos@redhat.com> wrote:
>>>> On 10/21/2014 06:47 PM, Roland McGrath wrote:
>>>>> But the slippery slope concerns me most of all.
>>>>
>>>> Any function the user interposes acts as a synchronous interrupt on the
>>>> runtime.
>>>>
>>>> It is my opinion that users expect to be able to call any routine in the
>>>> runtime without caution unless we tell them otherwise.
>>>>
>>>> Given that dlopen locks are recursive, as are stdio locks, I propose we
>>>> fully support this notion that users already believe exists.
>>>>
>>>> The alternative is that we don't support it and treat interposed functions
>>>> as if they were in a signal handler context, only being allowed to call
>>>> async-signal-safe functions, and we might as well remove the recursive
>>>> support from the locks such that users get useful backtraces from deadlocks.
>>>> It is my opinion that such a direction would not help our users and would
>>>> not help the project.
>>>>
>>>> The similar situations we need to clarify are LD_AUDIT modules, and
>>>> IFUNC resolvers, but let us proceed orderly one topic at a time.
>>>>
>>>> In summary
>>>> ==========
>>>>
>>>> Allow interposed functions to call back into the runtime, and fix any
>>>> places where this breaks.
>>>
>>> Do you have a plan to fix dlsym similarly? ISTR that pretty reliably
>>> trips on the same issue when used in a malloc hook.
>>
>> If you can write a test case I will look at it.
>
> I'll see what I can do. Are you looking for a glibc testcase or just a
> reproducer?
Just a reproducer. Please try to make it minimal. For example my reproducer
here was pretty small, install malloc hook, dlopen something, have malloc
hook dlopen something else, boom.
Cheers,
Carlos.