From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id E90413858D28 for ; Mon, 7 Aug 2023 12:59:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E90413858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6bcbb0c40b1so3388537a34.3 for ; Mon, 07 Aug 2023 05:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1691413145; x=1692017945; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=GSReWc8UZSo16KuaBenZjczdSaoFbJLUG4Q5g60zxDU=; b=DE6qJjbf5Q+5In2qd3ck+u5CzrjfvZx1ZcV4Rxdjlj/JE+fJOai/mvYIql2kK21LAw 5ijalinfGaKzIDiHrs8T1TvHFcGMXrZspnPULvTnrIF+Bseu5dTTWU6K75uvUpD135gz A2SbfjVMMKSmaBt5/KqWy0PTo0SJdi7bG29SQuU4+PI0xsogThiHCZRa+lCh37yq34eh Gh3UOWUScWqE/EimCh2i3D8tSlv5Fm5sIPkcHcdYq/0C3dUcfUFsMha04atBhP3sC7l8 mUxBwswgckMn6d4ZEhPOknJMnp7qv1jPHCX9+MFBmQYNySY/ntv//WJeFASZZ7zjzMGv FHhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691413145; x=1692017945; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GSReWc8UZSo16KuaBenZjczdSaoFbJLUG4Q5g60zxDU=; b=FU4V91Fr8uTYV+iK6VU4/wY2aAHz2Y0xzNaUkKSzPvNeCof0Jp54RVKSWR1VA9nHs0 8N+bDkc2DVL+WZ4mvWveGftzBOPN6c6yZ2RQExD8tZqbYM8wwxNTLSH8cBgZnuKNOn1C +90uKi+OjmvOjCX3+iE421mVhkLz+Frqm6aK4GhOuexfrH3EsHNaUlJ1AjzXx9vozGLO BJfKOoZW9jR1PwH2WmFPPKr7/anef70joM7xI+pDN+lRrBh5jmSSGoo8o/D7otcXgBfe BgF5DaSvRk5o2BGBZ8UHapUpVrmi1OjkYoDDjbMFzdbhE/yQF00j+jaKLmgEeV+5d0Fe WvJg== X-Gm-Message-State: AOJu0YzULZmotoYj2r5zU5XDpFB6YyhCRnYGL1O5TSAO43lKfbu8yiUx p5YlL3wv5bfM+fleHAmAmIqzsVUb2j3FbuqM1iKV5A== X-Google-Smtp-Source: AGHT+IEbZkZZZgvry4d2DBjEkeUZCjormec/35wv5Yid2lzVAZu2wiWeNurBpNc4NnoDJnaIEX+pEg== X-Received: by 2002:a05:6870:7010:b0:1bb:5480:4b4 with SMTP id u16-20020a056870701000b001bb548004b4mr10621062oae.8.1691413145089; Mon, 07 Aug 2023 05:59:05 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:9aa9:a52b:db0c:2e25:b2c4? ([2804:1b3:a7c1:9aa9:a52b:db0c:2e25:b2c4]) by smtp.gmail.com with ESMTPSA id s1-20020a4aad41000000b0056d361ca33fsm4217870oon.16.2023.08.07.05.59.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Aug 2023 05:59:04 -0700 (PDT) Message-ID: Date: Mon, 7 Aug 2023 09:59:01 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v2 1/2] setjmp: Use BSD sematic as default for setjmp Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org, Carlos O'Donell References: <20230803173436.4146900-1-adhemerval.zanella@linaro.org> <20230803173436.4146900-2-adhemerval.zanella@linaro.org> <87bkfndwop.fsf@oldenburg.str.redhat.com> <877cq7f1xr.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <877cq7f1xr.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 07/08/23 09:54, Florian Weimer wrote: > * Adhemerval Zanella Netto: > >> On 04/08/23 05:43, Florian Weimer wrote: >>> * Adhemerval Zanella: >>> >>>> POSIX relaxed the relation of setjmp/longjmp and the signal mask >>>> save/restore, meaning that setjmp does not require to be routed to >>>> _setjmp to be standard compliant. >>>> >>>> This is done to avoid breakage of SIGABRT handlers, since to fully >>>> make abort AS-safe, it is required to remove the recurisve lock >>>> used to unblock SIGABRT prior raised the signal. >>>> >>>> Also, it allows caller to actually use setjmp, since from >>>> 7011c2622fe3e10a29dbe74f06aaebd07710127d the symbol is unconditionally >>>> routed to _setjmp. >>> >>> I still think we shouldn't do this due to the performance implications. >> >> By not changing it and with the abort AS-safe fix, the following code >> will always abort the program: >> >> -- >> static jmp_buf jb; >> >> static void >> sigabrt_handler (int sig) >> { >> longjmp (jb, 1); >> } >> >> struct sigaction sa = { .sa_handler = sigabrt_handler, .sa_flags = 0 }; >> sigemptyset (&sa.sa_mask); >> assert (sigaction (SIGABRT, &sa, 0) == 0); >> >> if (setjmp (jb) == 0) >> abort (); >> >> if (setjmp (jb) == 0) >> abort (); >> >> // No reached. >> -- >> >> Callers will need to change to sigsetjmp (..., 1) to have the same semantic. >> That's the main reason I am suggesting this patch. > > Could we just unconditionally unblock SIGABRT at the start of abort, > before the raise (SIGABRT) call? Other signal handlers could still > observe this, but I think this change isn't really part of the core > async signal safety fix. My understanding is this still subject to same race condition with fork and posix_spawn signal handling setup, and that's why I have removed it. And we can't take a lock, even recursive, because it would prevent _Fork to be fully AS-safe.