[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