From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: [musl] Deadlock in dynamic linker?
Date: Sat, 24 May 2025 07:45:45 +0200 [thread overview]
Message-ID: <aDFdCWTMKj4-79U1@voyager> (raw)
Hi all,
I have a question about the handling of shutting_down in the dynamic
linker. Namely, I saw that do_init_fini() will go into an infinite wait
loop if it is set. The idea was probably to park initializing threads
while the system is shutting down, but can't this lead to a deadlock
situation?
I'm thinking something like this: Thread A initializes liba.so. liba.so
has initializers and finalizers, so thread A adds liba.so to the fini
list before calling the initializers. The liba initializer calls
dlopen("libb.so"). libb.so also has initializers.
While thread A is not holding the init_fini_lock, thread B calls exit().
That progresses until __libc_exit_fini() sets shutting_down to 1. Then
it tries to destroy all the libraries, but the loop stops when it comes
to liba.
liba.so has a ctor_visitor, namely thread A, so thread B cannot advance.
Thread A meanwhile is hanging in the infinite wait loop trying to
initialize libb.so. The situation cannot change, and the process hangs
indefinitely.
A simple way out of this pickle could be to add liba.so to the fini list
only after it was initialized. That way, thread B cannot hang on it, or
more generally, the finalizing thread cannot be halted by an incomplete
initialization in another thread. This might change the order of nodes
on the fini list, but only to account for dynamic dependencies. Isn't
that a good thing?
Ciao,
Markus
next reply other threads:[~2025-05-24 5:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-24 5:45 Markus Wichmann [this message]
[not found] ` <20250527152007.GO1827@brightrain.aerifal.cx>
2025-05-27 16:59 ` Markus Wichmann
2025-05-27 18:26 ` Rich Felker
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aDFdCWTMKj4-79U1@voyager \
--to=nullplan@gmx.net \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).