determine whether code is running in a signal handler context

Szabolcs Nagy szabolcs.nagy@arm.com
Mon Oct 23 10:01:00 GMT 2017


On 22/10/17 07:06, Carlos O'Donell wrote:
> 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:
>>> 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?

it means that as-unsafe code may interrupt the call.
(so if call is as-safe then there is no problem,
otherwise there is)

in practice this kind of design (where the signal handler
is as-unsafe and the main code is as-safe) is very rare,
but it is a valid design (e.g. think async-cancellation:
the main code is as-safe, and the interrupting code is
as-unsafe since it exits the thread running dtors etc).

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

ok, with the assumption that the library call is only
required to be as-safe in signal handlers.

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

ok.



More information about the Libc-help mailing list