This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH] Reinitialize dl_load_write_lock on fork (bug 19282)


On 10/09/2017 10:39 AM, Zack Weinberg wrote:
> On Mon, Oct 9, 2017 at 11:25 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> I agree with your sentiment, some of this needs to be supported, but
>> it will also need a new safety classification in the manual to describe
>> which interfaces are safe. Until we do this work, I agree with Andreas
>> that these uses are in theory INVALID. The same issues apply to SR-safety
>> which we discussed a year or two ago i.e. when is it safe for a function
>> to re-enter libc e.g. dlopen->malloc->dlopen (happens mostly with interposed
>> malloc).
> 
> Every time this stuff comes up I wonder whether it would be feasible
> to reduce the scope of the locks held by dlopen, especially to avoid
> holding locks while user-controlled code is running.

It is feasible, and it's exactly what we want to do IMO. I keep thinking
we want something like RCU in the dynamic loader, because that might allow
us to drop locks when calling foreign functions. The slow case is dlopen,
as it should be, though we could make startup just as fast as we are now,
in the single-threaded case.

We've been circling this drain for a while, and the only impediment
is fixing all the other broken stuff that is slightly higher priority.
As I may have mentioned already, I have plans to work on more dynamic
loader internals to try solve the TLS access problems we have. That won't
be until early next year though. So anyone else who wants to look at it is
more than welcome.

-- 
Cheers,
Carlos.


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