From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12856 Path: news.gmane.org!.POSTED!not-for-mail From: Patrick Oppenlander Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthread cancel cleanup and pthread_mutex_lock Date: Wed, 30 May 2018 10:06:17 +1000 Message-ID: References: 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 1527638669 29155 195.159.176.226 (30 May 2018 00:04:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 30 May 2018 00:04:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12872-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 30 02:04:25 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 1fNobG-0007RN-MN for gllmg-musl@m.gmane.org; Wed, 30 May 2018 02:04:22 +0200 Original-Received: (qmail 24223 invoked by uid 550); 30 May 2018 00:06:30 -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 24190 invoked from network); 30 May 2018 00:06:29 -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=vwiVudrj9nE6rSLddmgNm98mECeMmFfNO9oHTv5oV1Y=; b=W0GWhcSpuXWtuV7YooIE4wEyXYMGtrEW35f3FOjNVBsyy0DQ6iB2JMvVRnYCtBkzt6 4O+4mICO3FiOcLadrQ206L9lSRSlo+YXcZjTCptTHV/qXLSseNmfgh4Gk/FN16UdNFrw lSv8a5rayKAmfGQ690V1SwiTxPUodTqh1bKZ2hdISJQUOjQImwED9BpB+WySof3DbiO8 czS25svbVy8jMDH02MKQOMj2dKmISVP8XwYDpHgdj0giQCdfzX3ANHANvx5hOW8JtIpS vp988ISy47Q8c8FmTiPoAsg5EtpxFPymeMINx9SIqRcbaNxRrm365aW+31ZPCuZMOEM+ hQfg== 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=vwiVudrj9nE6rSLddmgNm98mECeMmFfNO9oHTv5oV1Y=; b=FWzmgeBJyr3NjGYeL/LAYxjaYllaZrz3jc9zCaaggwkKRGxcvANVAVBc8NFvlWD7T0 Yj4y20Wo37PpYk5plViZt+/+NSf7rLbq3JhYzoB322TXp5wHhisa2tP1hLeUR/B6/ntL WIU5aGCZAlP0W32RRpbnKs/RUPMhciWFyUDJBF/rEEi7Tmk0vafb3Zc5fC5vQ5lyfXin Badl9fRUZ+5M1rMB+oQJDqCOCBf5c2l4CdiOaeF2sDW/pZVVewq8LyfRAF8yCv3fOhb3 jG5L/f+tvwFoqAUvVBen2vYMKtLz2sklkSbJVGTLMGDmVyEPzFD4dUwCe7pupa9txIMW f7ug== X-Gm-Message-State: APt69E1Lox2A8FIU5RW/ceqT0LvmsT8BBSY86jJxXkHi19De/zoXfi80 tMQrWgCtSKOQXuFHrSB/olmmuIdKxAwFAqYo4a/o0g== X-Google-Smtp-Source: ADUXVKKZLtufMvIv2ThZZZG7y75pa0GGsQlWQxCpW93AMK98wTUN6iqYS+1MemsT3BDl0dhAv52zpko7zDGYJp+K1Ao= X-Received: by 2002:a0c:e211:: with SMTP id q17-v6mr514727qvl.240.1527638777504; Tue, 29 May 2018 17:06:17 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12856 Archived-At: I accidentally hit send before I finished typing.. > I've recently been running some of the open posix testsuite tests from > the linux test project. > > One particular test has been giving me headaches: > https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_mutex_init/1-2.c > > There are a couple of different tests in there but the most > interesting one is the deadlock test which does the following: > > Thread A: Thread B: > pthread_create > pthread_cleanup_push(...) > pthread_mutex_lock(M) > pthread_setcanceltype(ASYNC) > pthread_setcancelstate(ENABLE) pthread_mutex_lock(M) <-- blocks here pthread_cancel(B) pthread_join(B) The test then expects the cleanup handler to run and unlock mutex M allowing thread B to run to completion and the join to succeed. 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 I'm not even sure that this test is valid -- I can't find any documentation which says that pthread_mutex_lock is a cancellation point, or that you're allowed to call pthread_mutex_unlock from an async cancel handler. However, it's still concerning to see different results on different platforms. What's the expected behaviour here? Patrick