From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12858 Path: news.gmane.org!.POSTED!not-for-mail From: Patrick Oppenlander Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: pthread cancel cleanup and pthread_mutex_lock Date: Wed, 30 May 2018 11:36:55 +1000 Message-ID: References: <20180530005009.GM1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1527644128 29621 195.159.176.226 (30 May 2018 01:35:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 30 May 2018 01:35:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12874-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 30 03:35:24 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fNq1I-0007Z0-O3 for gllmg-musl@m.gmane.org; Wed, 30 May 2018 03:35:20 +0200 Original-Received: (qmail 1593 invoked by uid 550); 30 May 2018 01:37:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1567 invoked from network); 30 May 2018 01:37:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5Pqe/zgKQc5lEgRHIz4pNEHs2TcAnHtBeRfwhBdFCe4=; b=RL8/1CyF4AdTrNDSEciU6BvuoH/zxsweRtVcy03McjDT/ZB68MDkwecVymQrHinJPE c8Bn8BadiaJV3YhFgVhmDNGL2jxQq8hOzSdRqm9yCqo6gqLb1gkbfHcfbjxe3S4+yIA9 acdRemNeVAbpdK6vH082vsC2Mn1a4ncKakwgVc7YtTvvBEIpAiVUXUess5J0RLLqmPN3 5lyNYE7LmtgiVXaDP8gufc8yW4OYJ3dySdeZav5Ut0EUwRmLqBmV8LOJ3c7zuDfR9tO2 gG6U0dqEQTDPP+xqmaJQ2uhR7y/4e6qjyax+kYzo0dandnz3w4GZs5mCBh23hUVzxARQ ED1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5Pqe/zgKQc5lEgRHIz4pNEHs2TcAnHtBeRfwhBdFCe4=; b=UmHbyY9KXGa23BVrGDLm2jKTOrBML1Kwoq3SFsFcbHinIb/0OQA+6xWLIVYR3DVnk/ 7dVxryrB/DKvboIxyhBZGtA7jYmxKetgCNwZytdQWMaoloAsH+WQ+YY+JtIDf8mm/K4b 59V3QBC0kDG20iI1Un+6Oc2pVaUav+fBYFothElSdfvmlzrkBlX6GScwlgwuTWBEL6Re FoQXOpIL6IZx3KbS+nBApoyaMKy/u0lGHnKXe2SBQunT9bLS+dpelm1ErbM8avEqpBHu ZgsXt+Sp5JpnR0EcuHNmJxQQWHIbcy+APKAG0GwKLxxv/d7WIGRWSWZ0vMQ+zquQhAOS UbWA== X-Gm-Message-State: APt69E38k56zCDPys483U6IvV4D8QTwN8pdBbe7l2Tuo+Ch/UbIc2a5y FYmtgFytxHE2RWjhjm7yHlxqzUgOl2NLkoBW0OuJhQ== X-Google-Smtp-Source: ADUXVKIhfTv+NcdSuIGzTXlU7ZNBR3jcqWRHHAxHuy4bolK4HGT2v5lAKXLVGV/+nlEmLCP4T0XxmGyQBOj0OYg/gR4= X-Received: by 2002:ac8:3548:: with SMTP id z8-v6mr676252qtb.161.1527644236615; Tue, 29 May 2018 18:37:16 -0700 (PDT) In-Reply-To: <20180530005009.GM1392@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12858 Archived-At: On Wed, May 30, 2018 at 10:50 AM, Rich Felker wrote: > This test is invalid. pthread_mutex_lock is not async-cancel-safe and > cannot legally be called while cancel type is async. I suspected as much. > FYI something like 50% of the "Open POSIX Test Suite" tests are > invalid; in the majority of cases they're testing some property after > undefined behavior has been invoked like here. Thanks. Do you know of any better tests? >> I've run this test with musl, glibc and on some different platforms >> with varying results: >> >> x86_64 linux 4.16.11, glibc: test runs to completion >> x86_64 linux 4.16.11, musl: deadlock (cleanup handler doesn't run) >> arm linux 4.16.5, musl: test runs to completion > > The test is invalid in other ways too, involving races. It attempts to > use sched_yield to ensure that the test thread enters > pthread_mutex_lock a second time, but there's no reason to expect that > to do anything, especially if there are sufficiently many cores (as > many or more than running threads). I suspect the different behaviors > come down to just different scheduling properties due to performance > differences, or something like that. Naively, I would expect the test > to "work" despite being invalid. The reason it doesn't "work" (besides being stupid) is because the cleanup handler isn't invoked while the thread is blocked in the pthread_mutex_lock call. Should it be in the async cancellation case? >> What's the expected behaviour here? > > Nothing meaningful. Thanks. Patrick