From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Carlos O'Donell <carlos@redhat.com>,
linux-man <linux-man@vger.kernel.org>,
libc-alpha <libc-alpha@sourceware.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: mtk.manpages@gmail.com
Subject: Re: [patch] Describe issues with cancellation points in signal handlers.
Date: Sat, 5 Oct 2019 14:48:52 +0300 [thread overview]
Message-ID: <165a5e50-6c0f-7464-44ae-e74ac10a6e55@gmail.com> (raw)
In-Reply-To: <953b30ef-6546-ab16-06cb-e9d8d179dce2@redhat.com>
Hello Carlos,
On 10/5/19 12:12 AM, Carlos O'Donell wrote:
> In a recent conversation with Mathieu Desnoyers I was reminded
> that we haven't written up anything about how deferred cancellation
> and asynchronous signal handlers interact. Mathieu ran into some
> of this behaviour and I promised to improve the documentation in
> this area to point out the potential pitfall.
>
> Thoughts?
I've applied this. If some review comments come it, I can
tweak the text.
Thanks!
Michael
> 8< --- 8< --- 8<
> In pthread_setcancelstate.3, pthreads.7, and signal-safety.7 we
> describe that if you have an asynchronous signal nesting over a
> deferred cancellation region that any cancellation point in the
> signal handler may trigger a cancellation that will behave
> as-if it was an asynhcronous cancellation. This asynchronous
> cancellation may have unexpected effects on the consistency of
> the application. Therefore care should be taken with asynchronous
> signals and deferred cancellation.
> ---
> man3/pthread_setcancelstate.3 | 5 ++++-
> man7/pthreads.7 | 9 +++++++++
> man7/signal-safety.7 | 5 +++++
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/man3/pthread_setcancelstate.3 b/man3/pthread_setcancelstate.3
> index 0237d572b..1a6fe45bf 100644
> --- a/man3/pthread_setcancelstate.3
> +++ b/man3/pthread_setcancelstate.3
> @@ -78,7 +78,10 @@ A cancellation request is deferred until the thread next calls
> a function that is a cancellation point (see
> .BR pthreads (7)).
> This is the default cancelability type in all new threads,
> -including the initial thread.
> +including the initial thread. Even with deferred cancellation a
> +cancellation point in an asynchronous signal handler may still
> +be acted upon and the effect is as-if it was an asynchronous
> +cancellation.
> .TP
> .B PTHREAD_CANCEL_ASYNCHRONOUS
> The thread can be canceled at any time.
> diff --git a/man7/pthreads.7 b/man7/pthreads.7
> index 06417d503..b39236c39 100644
> --- a/man7/pthreads.7
> +++ b/man7/pthreads.7
> @@ -564,6 +564,15 @@ not specified in the standard as cancellation points.
> In particular, an implementation is likely to mark
> any nonstandard function that may block as a cancellation point.
> (This includes most functions that can touch files.)
> +.in
> +.PP
> +It should be noted that even if an application is not using
> +asynchronous cancellation, that calling a function from the above list
> +from an asynchronous signal handler may cause the equivalent of
> +asynchronous cancellation. The underlying user code may not expect
> +asynchronous cancellation and the state of the user data may become
> +inconsistent. Therefore signals should be used with caution when
> +entering a region of deferred cancellation.
> .\" So, scanning "cancellation point" comments in the glibc 2.8 header
> .\" files, it looks as though at least the following nonstandard
> .\" functions are cancellation points:
> diff --git a/man7/signal-safety.7 b/man7/signal-safety.7
> index 3879a5aef..051702b76 100644
> --- a/man7/signal-safety.7
> +++ b/man7/signal-safety.7
> @@ -314,6 +314,11 @@ is likely to remove
> .BR fork (2)
> from the list of async-signal-safe functions.
> .\"
> +.IP * 3
> +Asynchronous signal handlers that call functions which are cancellation
> +points and nest over regions of deferred cancellation may trigger
> +cancellation whose behavior is as-if asynchronous cancellation had
> +occurred and may cause application state to become inconsistent.
> .SS Deviations in the GNU C library
> The following known deviations from the standard occur in
> the GNU C library:
>
next prev parent reply other threads:[~2019-10-05 11:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 21:12 [patch] Describe issues with cancellation points in signal handlers Carlos O'Donell
2019-10-05 11:48 ` Michael Kerrisk (man-pages) [this message]
2019-10-07 2:17 ` Carlos O'Donell
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=165a5e50-6c0f-7464-44ae-e74ac10a6e55@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.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 NNTP newsgroup(s).