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

["Zhaohaifeng(Clark,IAS-SWP)" <zhaohaifeng4@huawei.com>]

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