Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 06 Oct 2022 09:37:50 +0300
From: Alexey Izbyshev <>
Subject: MT fork and key_lock in pthread_key_create.c


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.


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.