From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16393 invoked from network); 18 Oct 2022 12:49:46 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 18 Oct 2022 12:49:46 -0000 Received: (qmail 26229 invoked by uid 550); 18 Oct 2022 12:49:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26196 invoked from network); 18 Oct 2022 12:49:40 -0000 From: "Zhaohaifeng(Clark,IAS-SWP)" To: "musl@lists.openwall.com" Thread-Topic: A question about a patch of __vm_wait and thread list lock in musl Thread-Index: Adji7DthR8P4X2g9RhOQBKiajHEqrQ== Date: Tue, 18 Oct 2022 12:49:27 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.59.125] Content-Type: multipart/alternative; boundary="_000_b6315067bb404eb3b7d8defad4481a20huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [musl] A question about a patch of __vm_wait and thread list lock in musl --_000_b6315067bb404eb3b7d8defad4481a20huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there I am reading the following patch, https://git.musl-libc.org/cgit/musl/commi= t/?id=3Dd26e0774a59bb7245b205bc8e7d8b35cc2037095, it says that "the __vm_wa= it operation can delay forward progress arbitrarily long if a thread holdin= g 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 li= ke that one thread doing the pthread_exit holds the thread list lock and wa= its 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 sc= enario does not exist. Is my conclusion right? BR Clark Zhao --_000_b6315067bb404eb3b7d8defad4481a20huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there

 

I am reading the following patc= h, https://git.musl-libc.org/cgit/musl/commit/?id=3Dd26e0774a59bb7245b205bc8e7= d8b35cc2037095, it says that “the __vm_wait operation can delay f= orward progress arbitrarily long if a thread holding the lock is interrupte= d 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 deadlo= ck scenario. We guess the deadlock occurs like that one thread doing the pt= hread_exit holds the thread list lock and waits for the vm lock, and anothe= r thread holding the vm lock is interrupted by a signal and tries to hold the thread list lock in the signal handler.<= o:p>

But the thread list lock relate= d functions are all AS-unsafe and shall not be called in signal hanlder. Fu= rther in musl before holding the thread list lock, the application signals = are all blocked. So it seems the deadlock scenario does not exis= t.

 =

Is my conclusion right?

 

BR

Clark Zhao

--_000_b6315067bb404eb3b7d8defad4481a20huaweicom_--