From: Christian Brauner <brauner@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>, Jens Axboe <axboe@kernel.dk>,
linux-fsdevel@vger.kernel.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
NeilBrown <neil@brown.name>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-mm@kvack.org, io-uring@vger.kernel.org,
"Christian Brauner (Amutable)" <brauner@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH 4/6] signal: only SIGKILL interrupts a coredumping task
Date: Tue, 15 Sep 2026 12:22:19 +0200 [thread overview]
Message-ID: <20260915-work-coredump-fixes-v1-4-f354ca41780c@kernel.org> (raw)
In-Reply-To: <20260915-work-coredump-fixes-v1-0-f354ca41780c@kernel.org>
The coredump client only accepts SIGKILL. I've massaged away
TIF_NOTIFY_SIGNAL in another patch series but it seems that
TIF_SIGPENDING also has some warts and causes truncated coredumps:
(1) cgroup v2 freezer isn't built on freezing. Instead,
cgroup_freeze_task() sets JOBCTL_TRAP_FREEZE and calls
signal_wake_up() on every task in the cgroup. That includes the
coredump client. The coredump client isn't able to act on the trap.
So a freeze that lands in while a coredump is written will block.
Moving a coredumping client into a frozen cgroup has the same
problem.
(2) retarget_shared_pending() doesn't take a coredump into account too.
So if a sibling thread is in the middle of changing the signal mask
or it exists with a pending signal that helpers points the signals
to other threads.
While it skips exiting threads it will target it at the coredump
client as the coredump client isn't yet exiting.
So it's related to PF_NO_NOTIFY_SIGNAL which I have sitting in
kernel-7.4.signal. We should be able to fix it this time by making
signal_pending() report only SIGKILL for a task
that has PF_DUMPCORE set.
A cgroup v2 freeze now waits for the dump to finish. The PM and cgroup
v1 freezers keep aborting it through dump_interrupted().
Basically, PM should be able to interrupt the dump. cgroup v1 freezers
are legacy crap we don't care about and cgroup 2 should wait(?).
Fixes: 403bad72b67d ("coredump: only SIGKILL should interrupt the coredumping task")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---
include/linux/sched/signal.h | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
index 70067ccfe2ba..3a7ff3416e57 100644
--- a/include/linux/sched/signal.h
+++ b/include/linux/sched/signal.h
@@ -386,6 +386,11 @@ static inline int task_sigpending(struct task_struct *p)
return unlikely(test_tsk_thread_flag(p,TIF_SIGPENDING));
}
+static inline int __fatal_signal_pending(struct task_struct *p)
+{
+ return unlikely(sigismember(&p->pending.signal, SIGKILL));
+}
+
static inline int signal_pending(struct task_struct *p)
{
/*
@@ -395,12 +400,12 @@ static inline int signal_pending(struct task_struct *p)
*/
if (unlikely(test_tsk_thread_flag(p, TIF_NOTIFY_SIGNAL)))
return 1;
- return task_sigpending(p);
-}
-
-static inline int __fatal_signal_pending(struct task_struct *p)
-{
- return unlikely(sigismember(&p->pending.signal, SIGKILL));
+ if (!task_sigpending(p))
+ return 0;
+ /* A coredumping task only stops for SIGKILL, see dump_interrupted(). */
+ if (unlikely(READ_ONCE(p->flags) & PF_DUMPCORE))
+ return __fatal_signal_pending(p);
+ return 1;
}
static inline int fatal_signal_pending(struct task_struct *p)
--
2.53.0
next prev parent reply other threads:[~2026-09-15 10:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 10:22 [PATCH 0/6] coredump & signals: an impossible affair Christian Brauner
2026-09-15 10:22 ` [PATCH 1/6] coredump: don't switch a dumper that has no files table Christian Brauner
2026-09-16 19:48 ` Chris Mason
2026-09-16 22:10 ` Christian Brauner
2026-09-17 1:51 ` NeilBrown
2026-09-17 8:49 ` user workers as coredumpers [Re: [PATCH 1/6] coredump: don't switch a dumper that has no files] table Christian Brauner
2026-09-18 12:28 ` Christian Brauner
2026-09-18 13:33 ` Christian Brauner
2026-09-20 15:15 ` Oleg Nesterov
2026-09-21 11:20 ` Christian Brauner
2026-09-15 10:22 ` [PATCH 2/6] fork: refuse new threads while a coredump is in progress Christian Brauner
2026-09-15 15:02 ` Oleg Nesterov
2026-09-16 11:30 ` Christian Brauner
2026-09-15 10:22 ` [PATCH 3/6] coredump: hold RCU while releasing parked threads Christian Brauner
2026-09-15 15:13 ` Oleg Nesterov
2026-09-16 11:30 ` Christian Brauner
2026-09-15 10:22 ` Christian Brauner [this message]
2026-09-15 10:22 ` [PATCH 5/6] coredump: parse a snapshot of core_pattern Christian Brauner
2026-09-15 10:22 ` [PATCH 6/6] io-wq: order the exit bit against worker creation task work Christian Brauner
2026-09-15 12:01 ` [PATCH 0/6] coredump & signals: an impossible affair Jens Axboe
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=20260915-work-coredump-fixes-v1-4-f354ca41780c@kernel.org \
--to=brauner@kernel.org \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=neil@brown.name \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox