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.