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

[Carlos O'Donell <carlos at redhat dot com>]

On 10/20/2017 10:48 AM, Szabolcs Nagy wrote:
> 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();
> }

I don't understand this example.

Could you expand on this please?

>> 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.

The false positive being that you run AS-safe code only,
but you *could* have run AS-unsafe if you'd accurately
tracked what kind of context you interrupted?

In that case I would not say or use the word "correct"
or "incorrect", since the code works, but it *might*
conservatively require you to run AS-safe only functions.
In that case it's a performance and algorithmic complexity
issue. It *is* correct because you never do anything that
is undefined according to the standard.

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

It is correct, but not precise.

> (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)

s/correct/precise/g

-- 
Cheers,
Carlos.