[musl] questions about __tl_lock

[musl] questions about __tl_lock

[guolongqiang]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

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.


[-- Attachment #2: Type: text/html, Size: 3993 bytes --]

Re: [musl] questions about __tl_lock

[Rich Felker]

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

答复: [musl] questions about __tl_lock

[guolongqiang]

Thank you for explaining. I didn't notice that the parameter of do_futex invoked in mm_release for linux kernel.

Although the kernel(linux kernel) uses shared option by default to do_futex(wakeup), I think libc can still use
private option to do futex wait, there's no question of correctness. This conclusion comes from the review of
the kernel code. Am I right?

If that's true, isn't it a matter of us rely on the kernel?

-----邮件原件-----
发件人: Rich Felker [mailto:dalias@libc.org] 
发送时间: 2024年8月10日 10:51
收件人: guolongqiang <guolongqiang@huawei.com>
抄送: musl@lists.openwall.com; xufengwei <xufengwei@huawei.com>
主题: 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

[musl] Re: 答复: [musl] questions about __tl_lock

[Rich Felker]

On Sat, Aug 10, 2024 at 03:28:45AM +0000, guolongqiang wrote:
> Thank you for explaining. I didn't notice that the parameter of do_futex invoked in mm_release for linux kernel.
> 
> Although the kernel(linux kernel) uses shared option by default to do_futex(wakeup), I think libc can still use
> private option to do futex wait, there's no question of correctness. This conclusion comes from the review of
> the kernel code. Am I right?
> 
> If that's true, isn't it a matter of us rely on the kernel?

You're free to use either in general if the futex word is not being
accessed at different addresses referring to the same physical
address, but they're different "namespaces" and you have to be
consistent which you use for a particular futex -- the wait and wake
operations must either both be private or both be non-private, or else
the wake will fail to wake the waiter.

In the case of the thread list lock, the waker is often linux
kernel/fork.c:mm_release, where it performs:

	put_user(0, tsk->clear_child_tid);
	do_futex(tsk->clear_child_tid, FUTEX_WAKE,
			1, NULL, NULL, 0, 0);

This is a non-private wake, so if we were performing a private wait,
we would never wake up.

Rich


> -----邮件原件-----
> 发件人: Rich Felker [mailto:dalias@libc.org] 
> 发送时间: 2024年8月10日 10:51
> 收件人: guolongqiang <guolongqiang@huawei.com>
> 抄送: musl@lists.openwall.com; xufengwei <xufengwei@huawei.com>
> 主题: 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