[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8e7aa290-1206-4758-9680-cb666979d3d7@redhat.com>
Date: Fri, 26 Jul 2024 17:06:42 -0400
From: Carlos O'Donell <carlos@...hat.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
Markus Wichmann <nullplan@....net>
Cc: libc-coord@...ts.openwall.com, libc-alpha@...rceware.org
Subject: Re: Re: [libc-coord] Making exit actually thread-safe
On 7/26/24 3:58 PM, Rich Felker wrote:
> On Fri, Jul 26, 2024 at 09:38:54PM +0200, Markus Wichmann wrote:
>> Am Thu, Jul 25, 2024 at 08:39:27AM -0400 schrieb enh:
>>> aye, but a program that calls exit() from an atexit() handler is
>>> working for me right now on Android, glibc, and macOS. so there's a
>>> user-visible behavior change here for any of those libcs that goes
>>> with a non-recursive mutex. (i think the same is true for musl too,
>>> but don't have a musl-based system to test on.)
>>
>> For musl, calling exit() from an atexit handler will work somewhat
>> normally, at the moment. __funcs_on_exit() can be called re-entrant from
>> a handler without a problem. I think that was mainly to enable calls to
>> atexit() from atexit handlers (whatever sense that makes), but a side
>> effect is that calling exit() should also work.
>>
>> Also note that calling exit() from a destructor (_fini() or DT_FINI or
>> such like) has significantly more adverse effects. In the dynamic
>> linking case, it reliably leads to a deadlock on the init_fini_lock. In
>> the static linking case, it leads to a re-entrant call to
>> libc_exit_fini(), which will call the same destructor again. Unless the
>> destructor took measures to prevent this, this will lead to infinite
>> recursion, and finally a process crash.
>
> Yes. If we were going to allow recursive calls to exit, we would need
> to either leave the case of call from dtor undefined, or add some
> mechanism so that a call from a dtor did something predictable and
> safe (like skipping all future dtors and going right to __stdio_exit,
> or behaving like _exit, etc.)
>
> Short of having a way to define it that we've reasoned to be safe and
> consistent, having it trap/abort seems the best course of action.
I lean slightly towards trap/abort, but I don't think I can make that change today
in glibc without breaking applications... even if the "skip subsequent destructors"
case you mentioned upthread is poor behaviour.
--
Cheers,
Carlos.
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.
