Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Oct 2022 09:28:47 -0400
From: Rich Felker <>
To: "Zhaohaifeng(Clark,IAS-SWP)" <>
Cc: "" <>
Subject: Re: 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,
> 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


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.