From: Carlos O'Donell <carlos@redhat.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>,
Yubin Ruan <ablacktshirt@gmail.com>
Cc: nd@arm.com, libc-help@sourceware.org
Subject: Re: determine whether code is running in a signal handler context
Date: Mon, 23 Oct 2017 14:30:00 -0000 [thread overview]
Message-ID: <6f49af6e-6336-b9c0-61b3-c14de26d98dd@redhat.com> (raw)
In-Reply-To: <59EDBE09.9010109@arm.com>
On 10/23/2017 03:01 AM, Szabolcs Nagy wrote:
> 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)
Understood. Thank you for the clarification.
> 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).
I agree completely. It is a valid design.
In this case, the proposed API would force considerable added
complexity.
>>>> 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.
Yes.
>>> 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.
Please forgive my pedantism. I want everyone reading this
thread in the future to understand that correct in this case
is about avoiding undefined behaviour e.g. interrupting an
AS-unsafe context and running more AS-unsafe code. Rather than
a performance/complexity issue where an API uses a heuristic
that causes you to be AS-safe more often than you should.
The implementation of the API we are talking about could choose
to ignore the less frequently used case of AS-safe program being
interrupted by an AS-unsafe handler, in order to simplify the
code required to implement the API. Otherwise, as you state,
you need to precisely track the context being interrupted.
I think we've probably hashed out this issue to its maximum
extent :-) Hopefully the original poster has had their question
answered.
--
Cheers,
Carlos.
next prev parent reply other threads:[~2017-10-23 14:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-18 14:18 Yubin Ruan
2017-10-18 18:34 ` Carlos O'Donell
2017-10-19 1:52 ` Yubin Ruan
2017-10-19 2:19 ` Carlos O'Donell
2017-10-19 2:39 ` Will Hawkins
2017-10-19 3:12 ` Carlos O'Donell
2017-10-19 4:07 ` Yubin Ruan
2017-10-19 4:56 ` Carlos O'Donell
2017-10-19 4:19 ` Will Hawkins
2017-10-19 4:01 ` Yubin Ruan
2017-10-19 2:59 ` Sean Conner
2017-10-19 3:12 ` Sean Conner
2017-10-19 3:51 ` Yubin Ruan
2017-10-19 7:10 ` Jeffrey Walton
2017-10-20 10:32 ` Szabolcs Nagy
2017-10-20 11:23 ` Yubin Ruan
2017-10-20 11:31 ` Szabolcs Nagy
2017-10-20 17:19 ` Carlos O'Donell
2017-10-20 17:48 ` Szabolcs Nagy
2017-10-22 6:09 ` Carlos O'Donell
2017-10-22 23:39 ` where is the definition of idtype_t supposed to live? John Lumby
2017-10-23 13:57 ` Florian Weimer
[not found] ` <BN6PR22MB16662DE3DFB590B3D6006F81A3460@BN6PR22MB1666.namprd22.prod.outlook.com>
2017-10-23 14:20 ` Florian Weimer
2017-10-23 10:01 ` determine whether code is running in a signal handler context Szabolcs Nagy
2017-10-23 14:30 ` Carlos O'Donell [this message]
2017-10-24 1:00 ` Yubin Ruan
2017-11-27 8:43 ` Yubin Ruan
2017-11-27 11:55 ` Florian Weimer
2017-11-27 12:50 ` Yubin Ruan
2017-11-27 12:51 ` Florian Weimer
2017-11-27 12:58 ` Adhemerval Zanella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f49af6e-6336-b9c0-61b3-c14de26d98dd@redhat.com \
--to=carlos@redhat.com \
--cc=ablacktshirt@gmail.com \
--cc=libc-help@sourceware.org \
--cc=nd@arm.com \
--cc=szabolcs.nagy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).