This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] nptl: Fix deadlock on atfork handler which calls dlclose (BZ#24595)
On 23/05/2019 16:50, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> The solution sounds correct, but I don't have a strong opinion if this
>> is really an improvement over a recursive lock plus a linked list. It
>> potentially adds 'free' calls in fork for multithread mode if list needs
>> to be deallocated. Also, since the locks is internal to register-atfork.c
>> we might have a better control to make the exported interfaces not
>> deadlock.
>
> Recursive locks do not prevent deadlocks if the callback launches
> threads. I'm not sure if this can be considered a stretch. If
> there's dlclose involved, their might also be dlopen, and threads
> launched from an ELF constructor and so on.
That's why I said the core issue is atfork handlers are really
underspecified, and maybe it would be better if we document more
thoughtfully what we really aim to support by atfork handlers.
>
> Furthermore, I'm not sure if the implementation of __unregister_atfork
> is correct. I think you have a potential use-after-free issue if the
> callback deregisters a fork handler.
>
The possible way I can think of is if an atfork handler from a module
try to dlclose itself and I am not sure how valid it is.
Anyhow, I will implement your suggestion and check the resulting code.
I really would like to avoid introduce a free call to fork again and
make this rather complex atfork handler simpler.