[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6cf9cc5562e17610392c0f9c2cc68316@ispras.ru>
Date: Thu, 06 Oct 2022 10:02:11 +0300
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: MT fork and key_lock in pthread_key_create.c
On 2022-10-06 09:37, Alexey Izbyshev wrote:
> Hi,
>
> I noticed that fork() doesn't take key_lock that is used to protect
> the global table of thread-specific keys. I couldn't find mentions of
> this lock in the MT fork discussion in the mailing list archive. Was
> this lock overlooked?
>
> Also, I looked at how __aio_atfork() handles a similar case with
> maplock, and it seems wrong. It takes the read lock and then simply
> unlocks it both in the parent and in the child. But if there were
> other holders of the read lock at the time of fork(), the lock won't
> end up in the unlocked state in the child. It should probably be
> completely nulled-out in the child instead.
>
Looking at aio further, I don't understand how it's supposed to work
with MT fork at all. __aio_atfork() is called in _Fork() when the
allocator locks are already held. Meanwhile another thread could be
stuck in __aio_get_queue() holding maplock in exclusive mode while
trying to allocate, resulting in deadlock.
Alexey
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.
