From: Oleg Nesterov <oleg@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Michael Kerrisk <mtk.manpages@gmail.com>,
linux-man@vger.kernel.org, libc-alpha@sourceware.org
Subject: Re: signals: Bug or manpage inconsistency?
Date: Tue, 30 May 2017 19:04:14 +0200 [thread overview]
Message-ID: <20170530170414.GA22463@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1705301750390.1950@nanos>
On 05/30, Thomas Gleixner wrote:
>
> So I found at least some explanation by studying the spec some more.
>
> There are two variants of ignored signals:
>
> 1) handler is SIG_IGN
>
> 2) handler is SIG_DFL and default action is 'ignore'
Yes, and note that sys_rt_sigaction() discard the pending signal in both cases.
So even with this change the logic won't look 100% consistent.
I can't comment, I never tried to understand the rationality behind the current
behaviour. But at least the sending path should never drop a blocked SIG_DFL
signal, there is no other way to ensure you won't miss a signal during exec.
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -70,6 +70,13 @@ static int sig_handler_ignored(void __us
> (handler == SIG_DFL && sig_kernel_ignore(sig));
> }
>
> +static int sig_handler_is_sigign(struct task_struct *t, int sig)
> +{
> + void __user *handler = sig_handler(t, sig);
> +
> + return handler == SIG_IGN;
> +}
> +
> static int sig_task_ignored(struct task_struct *t, int sig, bool force)
> {
> void __user *handler;
> @@ -91,7 +98,7 @@ static int sig_ignored(struct task_struc
> * unblocked.
> */
> if (sigismember(&t->blocked, sig) || sigismember(&t->real_blocked, sig))
> - return 0;
> + return sig_handler_is_sigign(t, sig);
we can probably make a simpler change, but this doesn't matter.
Obviously this is a user-visible change and it can break something. Say, an
application does sigwaitinfo(SIGCHLD) and SIGCHLD is ignored (SIG_IGN), this
will no longer work.
I won't argue, but perhaps it is too late change this historical behaviour.
Although perhaps we can cleanup do_sigtimedwait() for the start. ->real_blocked
doesn't look nice. I think we can replace it with task->sigwait_mask and then
change sig_handler() to do
sigismember(sigwait_mask, sig) ? SIG_ERR :
t->sighand->action[sig - 1].sa.sa_handler;
this needs other changes, say, sig_fatal() will need to use sig_handler() too.
Then it would be more safe to drop the SIG_IGN signals unconditionally.
Oleg.
next prev parent reply other threads:[~2017-05-30 17:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-30 13:21 signals: Bug or manpage inconsistency? Thomas Gleixner
2017-05-30 16:14 ` Thomas Gleixner
2017-05-30 16:14 ` Thomas Gleixner
2017-05-30 17:04 ` Oleg Nesterov [this message]
[not found] ` <20170530170414.GA22463-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-05-30 17:19 ` Linus Torvalds
2017-05-30 17:19 ` Linus Torvalds
[not found] ` <CA+55aFygrsUhzQzEOX7YLzxMWE_GbKhJjQZ7nSDXnFFbRAWCJA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-30 19:18 ` Oleg Nesterov
2017-05-30 19:18 ` Oleg Nesterov
2017-05-30 20:54 ` Thomas Gleixner
2017-05-30 20:54 ` Thomas Gleixner
2017-05-31 0:48 ` Eric W. Biederman
2017-05-31 0:48 ` Eric W. Biederman
[not found] ` <87wp8xn96d.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-05-31 1:10 ` Eric W. Biederman
2017-05-31 1:10 ` Eric W. Biederman
2017-05-30 17:04 ` Linus Torvalds
2017-05-30 17:04 ` Linus Torvalds
[not found] ` <CA+55aFwC_8RWygnZWtgT+COY8mGY_RnDSW_vrD=+1x_NyPxChw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-30 19:35 ` Thomas Gleixner
2017-05-30 19:35 ` Thomas Gleixner
2017-05-30 19:58 ` Linus Torvalds
2017-05-30 19:58 ` Linus Torvalds
[not found] ` <CA+55aFxhMrsBWCqw--s9defz257ruwBED5NHWzkJqpU3jGJhCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-30 21:00 ` Thomas Gleixner
2017-05-30 21:00 ` Thomas Gleixner
2017-05-31 6:51 ` Michael Kerrisk (man-pages)
2017-05-31 6:51 ` Michael Kerrisk (man-pages)
2017-06-01 7:01 ` Eric W. Biederman
2017-06-01 7:01 ` Eric W. Biederman
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=20170530170414.GA22463@redhat.com \
--to=oleg@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.