[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aGS1zWJgC6yl4qP0@voyager>
Date: Wed, 2 Jul 2025 06:30:33 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: rebecca.zhang.cn@...driver.com, wenbin.deng.cn@...driver.com
Subject: Re: [PATCH] __libc_exit_fini forgets to do
pthread_mutex_unlock
Am Wed, Jul 02, 2025 at 10:28:54AM +0800 schrieb rebecca.zhang.cn@...driver.com:
> From: Rebecca Zhang <rebecca.zhang.cn@...driver.com>
>
> This commit fixes the issue that __libc_exit_fini only do
> pthread_mutex_lock, but forget to do pthread_mutex_unlock.
> ---
> ldso/dynlink.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> index ceca3c9..7885675 100644
> --- a/ldso/dynlink.c
> +++ b/ldso/dynlink.c
> @@ -1492,6 +1492,7 @@ void __libc_exit_fini()
> fpaddr(p, dyn[DT_FINI])();
> #endif
> }
> + pthread_mutex_unlock(&init_fini_lock);
> }
>
> void __ldso_atfork(int who)
> --
> 2.34.1
>
I think that is a deliberate omision. __libc_exit_fini() is called on
process exit. After it runs, it must not run again, and no new
initializer must run at all. The process will exit very soon anyway. The
only way to deadlock here is if a destructor calls exit(), which they
aren't allowed to do.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
