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 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.

zw


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