Re: determine whether code is running in a signal handler context

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 20/10/17 18:19, Carlos O'Donell wrote:
> On 10/20/2017 04:31 AM, Szabolcs Nagy wrote:
>> this entire mailing list thread assumes that only as-safe
>> code may run in a signal handler and that is wrong.
> 
> Correct.
> 
> I didn't want to go down more complex scenarios.
> 
>> your api proposal does not make sense in a posix libc.
>> (which explains why it does not exists)
>>
> 
> Conservatively, if you see you are in a signal handler, 
> and always run AS-safe code, you are always safe.
> 

yes, with as-safe code your are always safe.

> The converse is true too, if such an API call says you are
> *not* in a signal handler, you may always run AS-unsafe
> code because you know you could not have interrupted
> AS-unsafe code.
> 

that is usually true but may be false: if the
programmer thinks a call is as-safe when it isn't
that can cause problems even if the call is not in
a signal handler:

int main()
{
register_as_unsafe_handler();
call(); // ok if as-safe, not ok if as-unsafe
mask_signals();
}

> The API could still have its uses?
> 

yes it may have uses, but if a library tries to use
it for sanity checks, then the false positives will
cause headaches when somebody tries to use the
library correctly from a signal handler.

so it's a lot of complication for a not quite correct
check whether as-unsafe libc api is async reentered.

(e.g. a correct check would be inc/dec of a tls
counter in every as-unsafe libc api on entry/exit
and checking the counter, the libc could do this
without a public api change, may be possible to do
as an ld_preload hack if somebody really cares..
of course there are complications with callbacks
and, calls that go back to libc via plt etc, but
i think this can be made correct unlike the signal
context check)