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 5766 invoked from network); 6 Oct 2022 13:03:12 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 6 Oct 2022 13:03:12 -0000
Received: (qmail 28257 invoked by uid 550); 6 Oct 2022 07:02:59 -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 28225 invoked from network); 6 Oct 2022 07:02:58 -0000
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 793ED4229216
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru;
	s=default; t=1665039731;
	bh=EjBGXOi4C8gMxadAWtpoAgj1Z4hK5WpmbjzAswKpEnk=;
	h=Date:From:To:Subject:Reply-To:In-Reply-To:References:From;
	b=gW3f8y0xDMHLC2tLVihbk9KLI1R+9c4cMO84bTP3T45psdfatbj+SXWeL7yuRwkwy
	 fkTQ+1igEvVxtzmdgstbrmYyJNJsDfhN6Z6O/1vccFJOKoiQPemGX93rkSlwx3xSTv
	 INb9c3rbI59eK1CDVqP0fEkh5jrmj4zzh50kYBP0=
MIME-Version: 1.0
Date: Thu, 06 Oct 2022 10:02:11 +0300
From: Alexey Izbyshev <izbyshev@ispras.ru>
To: musl@lists.openwall.com
Mail-Followup-To: musl@lists.openwall.com
In-Reply-To: <033092a85a52d9f8e8d73a235e2381ae@ispras.ru>
References: <033092a85a52d9f8e8d73a235e2381ae@ispras.ru>
User-Agent: Roundcube Webmail/1.4.4
Message-ID: <6cf9cc5562e17610392c0f9c2cc68316@ispras.ru>
X-Sender: izbyshev@ispras.ru
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: [musl] 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