From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-21264-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,
	RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4
Received: from second.openwall.net (second.openwall.net [193.110.157.125])
	by inbox.vuxu.org (Postfix) with SMTP id DA89821584
	for <ml@inbox.vuxu.org>; Sat, 10 Aug 2024 04:51:39 +0200 (CEST)
Received: (qmail 28216 invoked by uid 550); 10 Aug 2024 02:51:34 -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 28175 invoked from network); 10 Aug 2024 02:51:33 -0000
Date: Fri, 9 Aug 2024 22:51:26 -0400
From: Rich Felker <dalias@libc.org>
To: guolongqiang <guolongqiang@huawei.com>
Cc: "musl@lists.openwall.com" <musl@lists.openwall.com>,
	xufengwei <xufengwei@huawei.com>
Message-ID: <20240810025125.GD10433@brightrain.aerifal.cx>
References: <f2bad7e008a1418dbcbba6fb8af2446c@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f2bad7e008a1418dbcbba6fb8af2446c@huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] questions about __tl_lock

On Fri, Aug 09, 2024 at 03:21:23AM +0000, guolongqiang wrote:
> Hi, all
>          I have one question about __tl_lock. The current implementation of __tl_lock shown as follow.
> Obviously __thread_list_lock is a private memory, why don't we pass FUTEX_PRIVATE option to __wait?
> 
> ```
> void __tl_lock(void)
> {
> int tid = __pthread_self()->tid;
> int val = __thread_list_lock;
> if (val == tid) {
> tl_lock_count++;
> return;
> }
> while ((val = a_cas(&__thread_list_lock, 0, tid)))
> __wait(&__thread_list_lock, &tl_lock_waiters, val, 0);
> }
> ```
> Thank you to explain.
> 

The thread list wait operation has to use a non-private futex wait
because the wake operation will be performed by the kernel, which
performs a non-private wake because that was the original contract
from before private futex operations existed.

Ideally when private waits were added, the kernel exit code path
should have been updated to do both private and non-private wakes so
that either type of wait would work. But that was overlooked, so even
if it were fixed in the kernel now, we couldn't rely on that.

Rich