Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 06 Oct 2022 10:02:11 +0300
From: Alexey Izbyshev <>
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.


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.