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

[Zack Weinberg]

On Tue, Jul 23, 2024, at 12:04 PM, Adhemerval Zanella Netto wrote:
> On 23/07/24 10:49, 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 don't think making a compatibility-impacting change to fix such
>> an obscure bug is a good trade-off.

I'm inclined to think that making setjmp be sigsetjmp by default is more
likely to _hide_ bugs than _expose_ them, but ...

>> The kernel providing something like exit_signal (terminate the process
>> even if a signal handler is installed) would be a better way forward, in
>> my opinion.
>
> And I don't see the need of a new kernel interface for an issue that can
> be complete solved in userspace (and I think kernel developers would say
> the same thing, since this most likely will need a new syscall to solve a
> very specific userland issue).

... adding exit_signal() would mean that abort() didn't need to do locking at all,
which might actually be a strong enough argument for the kernel people.

zw