From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no
	version=3.4.4
Received: (qmail 31174 invoked from network); 6 Oct 2022 12:05:24 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 6 Oct 2022 12:05:24 -0000
Received: (qmail 9808 invoked by uid 550); 6 Oct 2022 06:38:40 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 9773 invoked from network); 6 Oct 2022 06:38:39 -0000
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 70B344229216
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru;
	s=default; t=1665038270;
	bh=Zwux7ZjUeC2oP62U343kIkx2B2cxn9Px+2xKQ0Nh6+8=;
	h=Date:From:To:Subject:Reply-To:From;
	b=RtC5loYR1XoE3kBF4EtAOCHoMSaK7eh1A5A4DGx+vpRs1Yatn3v6lGCcQXg6uP/n5
	 ctFKkxPC4Ri1duS8W4Y9L9hkIANr8N0VnwyNhVTTVfTMQVAtVl7daxoiMVUOrMIEKZ
	 AYKQhSS+Wq6lUo9v/oftFM19wmWnE0lfwNwzAhRo=
MIME-Version: 1.0
Date: Thu, 06 Oct 2022 09:37:50 +0300
From: Alexey Izbyshev <izbyshev@ispras.ru>
To: musl@lists.openwall.com
Mail-Followup-To: musl@lists.openwall.com
User-Agent: Roundcube Webmail/1.4.4
Message-ID: <033092a85a52d9f8e8d73a235e2381ae@ispras.ru>
X-Sender: izbyshev@ispras.ru
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: [musl] MT fork and key_lock in pthread_key_create.c

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.

Thanks,
Alexey