From: ebiederm@xmission.com (Eric W. Biederman)
To: <linux-kernel@vger.kernel.org>
Cc: "Kyle Huey" <me@kylehuey.com>, "Jens Axboe" <axboe@kernel.dk>,
"Peter Zijlstra" <peterz@infradead.org>,
"Marco Elver" <elver@google.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Peter Collingbourne" <pcc@google.com>,
"Alexey Gladkov" <legion@kernel.org>,
"Robert O'Callahan" <rocallahan@gmail.com>,
"Marko Mäkelä" <marko.makela@mariadb.com>,
linux-api@vger.kernel.org, "Al Viro" <viro@ZenIV.linux.org.uk>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Kees Cook" <keescook@chromium.org>
Subject: [PATCH 1/3] signal: In get_signal test for signal_group_exit every time through the loop
Date: Mon, 15 Nov 2021 23:32:50 -0600 [thread overview]
Message-ID: <875yssekcd.fsf_-_@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <87bl2kekig.fsf_-_@email.froward.int.ebiederm.org> (Eric W. Biederman's message of "Mon, 15 Nov 2021 23:29:11 -0600")
Recently while investigating a problem with rr and signals I noticed
that siglock is dropped in ptrace_signal and get_signal does not jump
to relock.
Looking farther to see if the problem is anywhere else I see that
do_signal_stop also returns if signal_group_exit is true. I believe
that test can now never be true, but it is a bit hard to trace
through and be certain.
Testing signal_group_exit is not expensive, so move the test for
signal_group_exit into the for loop inside of get_signal to ensure
the test is never skipped improperly.
This has been a potential since I added the test for signal_group_exit
was added.
Fixes: 35634ffa1751 ("signal: Always notice exiting tasks")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
kernel/signal.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 7c4b7ae714d4..986fa69c15c5 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2662,19 +2662,19 @@ bool get_signal(struct ksignal *ksig)
goto relock;
}
- /* Has this task already been marked for death? */
- if (signal_group_exit(signal)) {
- ksig->info.si_signo = signr = SIGKILL;
- sigdelset(¤t->pending.signal, SIGKILL);
- trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
- &sighand->action[SIGKILL - 1]);
- recalc_sigpending();
- goto fatal;
- }
-
for (;;) {
struct k_sigaction *ka;
+ /* Has this task already been marked for death? */
+ if (signal_group_exit(signal)) {
+ ksig->info.si_signo = signr = SIGKILL;
+ sigdelset(¤t->pending.signal, SIGKILL);
+ trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
+ &sighand->action[SIGKILL - 1]);
+ recalc_sigpending();
+ goto fatal;
+ }
+
if (unlikely(current->jobctl & JOBCTL_STOP_PENDING) &&
do_signal_stop(0))
goto relock;
--
2.20.1
next prev parent reply other threads:[~2021-11-16 5:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 3:41 [PATCH] signal: SIGKILL can cause signal effects to appear at PTRACE_EVENT_EXIT without tracer notification Kyle Huey
2021-11-01 3:41 ` [PATCH 1/2] signal: factor out SIGKILL generation in get_signal Kyle Huey
2021-11-01 3:41 ` [PATCH 2/2] signal: after notifying a ptracer of a signal, recheck for pending SIGKILLs Kyle Huey
2021-11-02 14:08 ` [PATCH] signal: SIGKILL can cause signal effects to appear at PTRACE_EVENT_EXIT without tracer notification Eric W. Biederman
2021-11-02 16:01 ` Kyle Huey
2021-11-02 18:06 ` Eric W. Biederman
2021-11-02 19:09 ` Kyle Huey
2021-11-08 23:58 ` Kyle Huey
2021-11-14 17:19 ` Eric W. Biederman
2021-11-16 5:29 ` [PATCH 0/3] signal: requeuing undeliverable signals Eric W. Biederman
2021-11-16 5:32 ` Eric W. Biederman [this message]
2021-11-16 18:23 ` [PATCH 1/3] signal: In get_signal test for signal_group_exit every time through the loop Kees Cook
2021-11-17 16:31 ` Eric W. Biederman
2021-11-16 5:33 ` [PATCH 2/3] signal: Requeue signals in the appropriate queue Eric W. Biederman
2021-11-16 18:30 ` Kees Cook
2021-11-17 16:42 ` Eric W. Biederman
2021-11-16 5:34 ` [PATCH 3/3] signal: Requeue ptrace signals Eric W. Biederman
2021-11-16 18:31 ` Kees Cook
2021-11-17 16:44 ` Eric W. Biederman
2021-11-17 16:24 ` [PATCH 0/3] signal: requeuing undeliverable signals Kyle Huey
2021-11-17 16:51 ` Eric W. Biederman
2021-11-18 6:12 ` Marko Mäkelä
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=875yssekcd.fsf_-_@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=axboe@kernel.dk \
--cc=elver@google.com \
--cc=keescook@chromium.org \
--cc=legion@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marko.makela@mariadb.com \
--cc=me@kylehuey.com \
--cc=oleg@redhat.com \
--cc=pcc@google.com \
--cc=peterz@infradead.org \
--cc=rocallahan@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.