From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by sourceware.org (Postfix) with ESMTPS id 425193857838 for ; Wed, 28 Oct 2020 20:17:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 425193857838 Received: by mail-qv1-xf33.google.com with SMTP id s1so412237qvm.13 for ; Wed, 28 Oct 2020 13:17:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zA72uV01xNXXa2M+lEIPAXPaWN/pNgs1dm2j3N1ggmw=; b=QRNbIMQMHmb7+a+CF+OSHaA84W5681tU1uWhailrv+9nw+0rDAtCoATc6aYbjTiVfW +rtiJCFpKAFGAUxeu32b5LDsi1lDuhU6NSO1fChulnnAZ+oyOwoK1KQPKzHRJ78Xisdu NkwxJKd9n+tmqI4xSFarLOoxJ1E1KcY8TPNgEIj3XDkyXzh4oPtUwh84z3uGl1rDa+8r 2BOKf8jXPpBbiR0LPr/QOo2xpKpSfEHBJU9+7nPTWEqFE7/NRfI6fVTmNdFF56fgMivb OR9kdEhgYAwsFqzQIr3RJ1E8MUKucgM51ecC9ORVQT7OrbWidUksg+8MIXhFiYU7jpCg n3xQ== X-Gm-Message-State: AOAM530TDELxA+YwiiyK0VroeFDth1WhKnifQeDvwEEnzqf7jWbEA7kA XxJOcaedAieYp8enh4tMHjNouffzy3MItA== X-Google-Smtp-Source: ABdhPJxEhNxy64yxRNtm98qNLbM8iEaC62cxQu10MrrwUm8AhIS9aCa5uMNDI/2a2sxK24gLGat2Eg== X-Received: by 2002:ad4:5901:: with SMTP id ez1mr928164qvb.56.1603916253667; Wed, 28 Oct 2020 13:17:33 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id x21sm266786qkb.78.2020.10.28.13.17.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 13:17:32 -0700 (PDT) To: Tadeus Prastowo <0x66726565@gmail.com> Cc: "libc-help@sourceware.org" , Florian Weimer References: <25b5791b-5368-7a78-f80d-5ceb2b618d72@linaro.org> <518e2a7c-74a3-d5dc-52c3-3fdddd5f7fa4@linaro.org> <76680377-32fb-bf34-5c1e-2dc63d1485c7@linaro.org> From: Adhemerval Zanella Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= mQINBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABtElBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+iQI3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AquQINBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABiQIfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Subject: Re: raise() marked __leaf__ is not C-compliant? Message-ID: <569317ca-b87a-68cc-a776-f524ec76ca3c@linaro.org> Date: Wed, 28 Oct 2020 17:17:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.6 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 20:17:36 -0000 On 28/10/2020 16:23, Tadeus Prastowo wrote: > On Wed, Oct 28, 2020 at 6:34 PM Adhemerval Zanella > wrote: >> >> On 28/10/2020 10:19, Tadeus Prastowo wrote: >>> On Wed, Oct 28, 2020 at 12:53 PM Adhemerval Zanella >>> wrote: >>>> >>>> The sentence "raise() definitely runs a signal handler" is not really >>>> valid in a portable sense. Afaik neither C nor POSIX states which signals >>>> should be delivered synchronously or asynchronously (although some do >>>> only make sense to be delivered synchronously such as SIGSEGV). >>>> >>>> However, Linux does ran some signals synchronously and I agree that using >>>> leaf attribute is incorrect and lead to this kind of problems. My point is >>>> to be fully portable, you need to assume any signal might be delivered >>>> asynchronously (and C standard specifies the volatile sig_atomic_t for >>>> such cases). >>> >>> Thank you for your response. >>> >>> However, C, including C99, C11, and the latest C18 [1], says: "If a >>> signal handler is called, the raise function shall not return until >>> after the signal handler does." And, POSIX [2] says: "If a signal >>> handler is called, the raise() function shall not return until after >>> the signal handler does." So, the sentence "raise() definitely runs a >>> signal handler" is valid in a portable sense as required by the >>> standards, no? >> >> My understanding is it allows synchronous signals, not enforce it; >> and if the signal is synchronous then it should complete prior hand. > > I understand your point as the C standard says: > > [...] distinct values that are the signal numbers, each corresponding > to the specified condition: > SIGABRT [...] > SIGFPE [...] > SIGILL [...] > SIGINT [...] > SIGSEGV [...] > SIGTERM [...] > An implementation need not generate any of these signals, except as a > result of explicit calls to the raise function. [...] The complete > set of signals, their semantics, and their default handling is > implementation-defined; all signal numbers shall be positive. > > [...] > > void (*signal(int sig, void (*func)(int)))(int); > Description > [...] > When a signal occurs and func points to a function, it is > implementation-defined whether the equivalent of signal(sig, SIG_DFL); > is executed [...]; in the case of SIGILL, the implementation may > alternatively define that no action is taken. Then the equivalent of > (*func)(sig); is executed. > > End quote. > > So, yes, you are right that the sentence "raise() definitely runs a > signal handler" is inaccurate because, as quoted above, C standard > allows an implementation to not run the handler that the user has > designated to handle the signal being generated by raise(). However, > if the implementation decides that "the equivalent of (*func)(sig); is > executed", then the C standard requires that "the raise function shall > not return until after the signal handler does." I agree this does make sense for *synchronous* signal triggering. My point ir neither C not POSIX specify which signal should be synchronous. In fact, afaik neither standard does make a clearly distinction nor specific the expected semantic for signal "synchronicity" (it is really implementation defined). > > To conclude, in my earlier post, I meant to say: Glibc-2.30 raise() > may run a signal handler that is defined in the current compilation > unit to use static variables. So, unless the C standard says that it > is an undefined behavior to access a non-volatile object with static > storage duration from within a signal handler that is called > synchronously by raise() on a normal execution path, the marking of > raise() with __leaf__ makes raise() non-compliant with the C standard. I am not a language lawyer here, and I agree with you that adding leaf attribute on 'raise' is wrong. But because glibc can't guarantee how the underlying kernel will trigger the signal in a raise syscall. I still think that once you can't assume the signal will be triggered synchronously, you can't also assume that accessing non-volatile object with static storage duration from within a signal handler might not trigger undefined behavior.