[PATCH v2 1/2] setjmp: Use BSD sematic as default for setjmp

[Adhemerval Zanella Netto]

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.