Date: Tue, 18 Oct 2022 09:28:47 -0400 From: Rich Felker <dalias@...c.org> To: "Zhaohaifeng(Clark,IAS-SWP)" <zhaohaifeng4@...wei.com> Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com> 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, > 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
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.