[musl] A question about a patch of __vm_wait and thread list lock in musl

[musl] A question about a patch of __vm_wait and thread list lock in musl

[Zhaohaifeng(Clark,IAS-SWP)]

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

Hi there

I am reading the following patch, https://git.musl-libc.org/cgit/musl/commit/?id=d26e0774a59bb7245b205bc8e7d8b35cc2037095, it says that "the __vm_wait operation can delay forward progress arbitrarily long if a thread holding the lock is interrupted by a signal. in a worst case this can deadlock." So the patch puts the vm wait before the thread list lock.

I am wondering about the deadlock scenario. We guess the deadlock occurs like that one thread doing the pthread_exit holds the thread list lock and waits for the vm lock, and another thread holding the vm lock is interrupted by a signal and tries to hold the thread list lock in the signal handler.
But the thread list lock related functions are all AS-unsafe and shall not be called in signal hanlder. Further in musl before holding the thread list lock, the application signals are all blocked. So it seems the deadlock scenario does not exist.

Is my conclusion right?

BR
Clark Zhao

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

Re: [musl] A question about a patch of __vm_wait and thread list lock in musl

[Rich Felker]

On Tue, Oct 18, 2022 at 12:49:27PM +0000, Zhaohaifeng(Clark,IAS-SWP) wrote:
> Hi there
> 
> I am reading the following patch,
> https://git.musl-libc.org/cgit/musl/commit/?id=d26e0774a59bb7245b205bc8e7d8b35cc2037095,
> it says that "the __vm_wait operation can delay forward progress
> arbitrarily long if a thread holding the lock is interrupted by a
> signal. in a worst case this can deadlock." So the patch puts the vm
> wait before the thread list lock.
> 
> I am wondering about the deadlock scenario. We guess the deadlock
> occurs like that one thread doing the pthread_exit holds the thread
> list lock and waits for the vm lock, and another thread holding the
> vm lock is interrupted by a signal and tries to hold the thread list
> lock in the signal handler.
> But the thread list lock related functions are all AS-unsafe and
> shall not be called in signal hanlder. Further in musl before
> holding the thread list lock, the application signals are all
> blocked. So it seems the deadlock scenario does not exist.
> 
> Is my conclusion right?

No. The whole point of the thread list lock is to be an
async-signal-safe lock so that we can access the thread list from
async signal contexts, particularly setuid() etc., which *are*
required to be AS-safe. See the commit that introduced it,
8f11e6127fe93093f81a52b15bb1537edc3fc8af and the followup commit
e4235d70672d9751d7718ddc2b52d0b426430768 that was the main motivation
for having a global thread list (but not the only one; having it
opened up a lot of other benefits like those in commit
9d44b6460ab603487dab4d916342d9ba4467e6b9).

Rich

答复: [musl] A question about a patch of __vm_wait and thread list lock in musl

[Zhaohaifeng(Clark,IAS-SWP)]

Thanks for the explanation. I've got the design idea of the thead list lock.

BR
Clark Zhao

-----邮件原件-----
发件人: Rich Felker [mailto:dalias@libc.org] 
发送时间: 2022年10月18日 21:29
收件人: Zhaohaifeng(Clark,IAS-SWP) <zhaohaifeng4@huawei.com>
抄送: musl@lists.openwall.com
主题: Re: [musl] A question about a patch of __vm_wait and thread list lock in musl

On Tue, Oct 18, 2022 at 12:49:27PM +0000, Zhaohaifeng(Clark,IAS-SWP) wrote:
> Hi there
> 
> I am reading the following patch,
> https://git.musl-libc.org/cgit/musl/commit/?id=d26e0774a59bb7245b205bc
> 8e7d8b35cc2037095, it says that "the __vm_wait operation can delay 
> forward progress arbitrarily long if a thread holding the lock is 
> interrupted by a signal. in a worst case this can deadlock." So the 
> patch puts the vm wait before the thread list lock.
> 
> I am wondering about the deadlock scenario. We guess the deadlock 
> occurs like that one thread doing the pthread_exit holds the thread 
> list lock and waits for the vm lock, and another thread holding the vm 
> lock is interrupted by a signal and tries to hold the thread list lock 
> in the signal handler.
> But the thread list lock related functions are all AS-unsafe and shall 
> not be called in signal hanlder. Further in musl before holding the 
> thread list lock, the application signals are all blocked. So it seems 
> the deadlock scenario does not exist.
> 
> Is my conclusion right?

No. The whole point of the thread list lock is to be an async-signal-safe lock so that we can access the thread list from async signal contexts, particularly setuid() etc., which *are* required to be AS-safe. See the commit that introduced it, 8f11e6127fe93093f81a52b15bb1537edc3fc8af and the followup commit
e4235d70672d9751d7718ddc2b52d0b426430768 that was the main motivation for having a global thread list (but not the only one; having it opened up a lot of other benefits like those in commit 9d44b6460ab603487dab4d916342d9ba4467e6b9).

Rich