From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,LOTS_OF_MONEY,MAILING_LIST_MULTI, MONEY_NOHTML,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1114E1F8C6 for ; Mon, 23 Aug 2021 10:06:56 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DB35D3853C07 for ; Mon, 23 Aug 2021 10:06:54 +0000 (GMT) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by sourceware.org (Postfix) with ESMTPS id AEB283857438 for ; Mon, 23 Aug 2021 10:05:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AEB283857438 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nefkom.net Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4GtSYM1wPSz1s9RW; Mon, 23 Aug 2021 12:05:43 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4GtSYM1flMz1r6Ph; Mon, 23 Aug 2021 12:05:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id VblaHjZdH_Ys; Mon, 23 Aug 2021 12:05:42 +0200 (CEST) X-Auth-Info: 1PIZ7yPz/erue08G0HXr7cNCPrqtWqlJ5z13GYYB/+zgTzLmoiN3VRwayIT38igi Received: from igel.home (ppp-46-244-177-181.dynamic.mnet-online.de [46.244.177.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Mon, 23 Aug 2021 12:05:42 +0200 (CEST) Received: by igel.home (Postfix, from userid 1000) id 926292C0962; Mon, 23 Aug 2021 12:05:41 +0200 (CEST) From: Andreas Schwab To: Florian Weimer Subject: Re: Async cacellation and pthread_cleanup_push References: <87zgtxuxa8.fsf@igel.home> <87fsvp9qcz.fsf@oldenburg.str.redhat.com> <87tuk5tcw8.fsf@igel.home> <87fsvp6vis.fsf@oldenburg.str.redhat.com> <87pmuttbyr.fsf@igel.home> <87tujgqywx.fsf@oldenburg.str.redhat.com> X-Yow: .. does your DRESSING ROOM have enough ASPARAGUS? Date: Mon, 23 Aug 2021 12:05:41 +0200 In-Reply-To: <87tujgqywx.fsf@oldenburg.str.redhat.com> (Florian Weimer's message of "Mon, 23 Aug 2021 11:43:26 +0200") Message-ID: <87mtp8scga.fsf@igel.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Aug 23 2021, Florian Weimer wrote: > * Andreas Schwab: > >> On Aug 04 2021, Florian Weimer wrote: >> >>> * Andreas Schwab: >>> >>>> On Aug 04 2021, Florian Weimer wrote: >>>> >>>>> * Andreas Schwab: >>>>> >>>>>> Is pthread_cleanup_push supposed to work together with async >>>>>> cancellation? >>>>> >>>>> In our implementation? I think so. >>>> >>>> I don't see how that can work with -fexceptions or in C++, though. Is >>>> that supported? >>> >>> I think it is supposed to work, but it probably is unreliable. >> >> Since the compiler puts the exception regions only over function calls >> (and -fnon-call-exceptions only covers potentially trapping insns in >> addition) the cleanup region will not be fully covered. > > I can see how this can happen in theory … This is not theory, it happens exactly here. >> testcases/open_posix_testsuite/conformance/interfaces/pthread_cancel/3-1.c > > … but I don't see how this applies to this particular test. There is a non-zero probability that the cancel signal arrives in thread_func and sleep_loop while it is executing the unprotected instructions outside of the .LEHB1 to .LEHE1 region: movl $sem, %edi call sem_post movq $0, (%rsp) movq $1000000, 8(%rsp) .p2align 4,,10 .p2align 3 .L2: xorl %esi, %esi movq %rsp, %rdi .LEHB1: call nanosleep subl $1, %ebx jne .L2 movl $.LC0, %edi call puts .LEHE1: Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."