From: Florian Weimer <fweimer@redhat.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Carlos O'Donell <carlos@redhat.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH] nptl: Fix deadlock on atfork handler which calls dlclose (BZ#24595)
Date: Fri, 24 May 2019 16:42:57 +0200 [thread overview]
Message-ID: <87pno7q5fy.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <0636dd42-5cdb-7bdd-5ad7-0614bad0da78@linaro.org> (Adhemerval Zanella's message of "Fri, 24 May 2019 10:24:19 -0300")
* Adhemerval Zanella:
> On 24/05/2019 08:06, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> 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.
>>
>> That's also true.
>>
>>>> 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.
>>
>> dlclose'ing itself is not really valid, I think. It can only work if
>> the dlclose call is a tail call.
>
> I would work towards not make dlclose itself valid, do you see any
> reason to allow to do so?
Sorry, what do you mean? Inspect the caller address and reject the
dlclose call if it's within the DSO being closed? This just avoids a
crash, instead resulting in a dlclose error return. Not sure if this is
particularly relevant.
>> __unregister_atfork still adds a use-after-free issue, even with the
>> copy-on-write list: If a dlclose unregisters a fork handler, we will
>> still attempt to call it subsequently if it was on the list before. No
>> data race is involved if the dlclose call happens itself in a fork
>> handler (so we are back to the territory of the bug).
>>
>> So the simple reference counting scheme I proposed is probably not the
>> right solution, and we need a different data structure
>
> My understanding is if the idea of dlclose on atfork handler is to
> not just unregister the library but also prevent further arfork handler
> to been called (since __cxa_finalize will call __unregister_atfork),
> I still think that the recursive mutex plus double-linked list is
> the best a suitable solution if we assume two premisses:
>
> - It is invalid to dlclose itself.
> - Atfork handlers should be local to modules.
>
> Both should avoid imho the use-after-free issue since the callback
> won't try to deregister an already used entry in atfork handler list
> walking.
I'm not sure about that. The dlclose could remove a fork handler that
has yet to be called. The handlers may not have been registered in load
order.
Thanks,
Florian
next prev parent reply other threads:[~2019-05-24 14:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 13:30 [PATCH] nptl: Fix deadlock on atfork handler which calls dlclose (BZ#24595) Adhemerval Zanella
2019-05-23 14:36 ` Carlos O'Donell
2019-05-23 14:53 ` Adhemerval Zanella
2019-05-23 17:31 ` Florian Weimer
2019-05-23 18:33 ` Adhemerval Zanella
2019-05-23 19:50 ` Florian Weimer
2019-05-23 23:46 ` Adhemerval Zanella
2019-05-24 11:06 ` Florian Weimer
2019-05-24 13:24 ` Adhemerval Zanella
2019-05-24 14:42 ` Florian Weimer [this message]
2019-05-24 14:49 ` Adhemerval Zanella
2019-07-08 13:11 ` Florian Weimer
2019-07-12 18:05 ` Adhemerval Zanella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pno7q5fy.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=adhemerval.zanella@linaro.org \
--cc=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).