[PATCH v2 0/2] Make abort AS-safe

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Wed Jul 24 16:57:02 GMT 2024



On 24/07/24 13:37, Florian Weimer wrote:
> * Zack Weinberg:
> 
>> On Wed, Jul 24, 2024, at 11:25 AM, Adhemerval Zanella Netto wrote:
>>> On 24/07/24 11:40, Zack Weinberg wrote:
>>>> Continuing the discussion from part 1 of your patch here as this message
>>>> provides important context:
>>>>
>>>> On Tue, Jul 23, 2024, at 9:41 AM, Adhemerval Zanella wrote:
>>>>> POSIX states that abort should be AS-safe
>>>> ...
>>>> [and now also states]
>>>>>   The SIGABRT signal shall be sent to the calling [CX]thread[/CX] as
>>>>>   if by means of raise() with the argument SIGABRT. [CX]If this signal
>>>>>   does not terminate the process (for example, if the signal is caught
>>>>>   and the handler returns), abort() may change the disposition of
>>>>>   SIGABRT to SIG_DFL and send the signal (in the same way) again. If a
>>>>>   second signal is sent and it does not terminate the process, the
>>>>>   behavior is unspecified, except that the abort() call shall not
>>>>>   return.
>>>>
>>>> It occurs to me that the new language does not require us to _succeed_
>>>> in changing the disposition of SIGABRT, which means "but what if other
>>>> threads race with us to change the disposition of SIGABRT?" is moot.
>>>> The only hard requirements that survive are:
>> ...
>>> This does not solve the issue of concurrent sigaction (SIGABRT), which is
>>> the main point of the locking (and on my patch the locks is taken iff for 
>>> SIGABRT disposition change).
>>
>> Uh, my whole point was that the new language permits us to ignore that issue.
> 
> Indeed.  And it seems to suggest that it's okay if a concurrently
> running execve picks up the SIG_DFL change.  The old POSIX language
> doesn't mention the SIG_DFL change, so I suppose the current
> abort/execve behavior (and the new one after this patch) was not allowed
> before.

So should we ignore concurrent sigaction for abort?  It does simplify the
implementation without the lock, although I am not sure if this is really
an improvement over current code regarding how parent seems the termination
state.


More information about the Libc-alpha mailing list