From: Christian Brauner <brauner@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>, Chris Mason <mason@kernel.org>,
linux-fsdevel@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>,
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 v3 02/17] signal: only SIGKILL and the freezers interrupt a coredumping task
Date: Mon, 21 Sep 2026 15:44:51 +0200 [thread overview]
Message-ID: <20260921-work-coredump-fixes-v3-2-8e4adb1619e6@kernel.org> (raw)
In-Reply-To: <20260921-work-coredump-fixes-v3-0-8e4adb1619e6@kernel.org>
For quite a while now coredump has allowed either SIGKILL or freezing to
interrupt an ongoing coredump. Since we seem to like it complicated
"freezing" can mean a lot of things:
(1) Power Management induced freezing
(2) cgroup v1 freezer controller induced freezing
(3) cgroup v2 freezer controller induced freezing
So (1) and (2) are handled by checking freezing() but (3) isn't.
(3) uses cgroup_freeze_task() which sets JOBCTL_TRAP_FREEZE and calls
signal_wake_up() on every task in the cgroup. The trap isn't handled by
the coredump code.
Which means the current logic is inconsistent. Power and cgroup v1
freeze and abort the coredump. With cgroup v2 it depends on where the
core goes. A dump to a file completes and the cgroup v2 freeze has to
wait for it to finish. When dumping to a pipe or socket the dump is
interrupted at the next write because of trap's TIF_SIGPENDING. Which is
it? Let's be consistent and align (1)-(3): freezing interrupts an
ongoing coredump and doesn't make it wait until the dump is done.
So make signal_pending() report only SIGKILL, freezing() and the cgroup
v2 freezer trap for a task that has PF_DUMPCORE set. freezing() lives in
linux/freezer.h and is a static branch. So keep that check a separate
helper instead of in signal_pending() itself.
Make dump_interrupted() check for JOBCTL_TRAP_FREEZE as well so a cgroup
v2 freeze keeps aborting the dump like PM and cgroup v1 do.
Fixes: 403bad72b67d ("coredump: only SIGKILL should interrupt the coredumping task")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---
fs/coredump.c | 11 ++++++-----
include/linux/sched/signal.h | 19 +++++++++++++------
kernel/signal.c | 8 ++++++++
3 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 6c0c597ec324..40eca2b85b81 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -580,12 +580,13 @@ static void coredump_finish(enum coredump_state state)
static bool dump_interrupted(void)
{
/*
- * SIGKILL or freezing() interrupt the coredumping. Perhaps we
- * can do try_to_freeze() and check __fatal_signal_pending(),
- * but then we need to teach dump_write() to restart and clear
- * TIF_SIGPENDING.
+ * SIGKILL, freezing() or the cgroup v2 freezer trap interrupt the
+ * coredumping. Perhaps we can do try_to_freeze() and check
+ * __fatal_signal_pending(), but then we need to teach dump_write()
+ * to restart and clear TIF_SIGPENDING.
*/
- return fatal_signal_pending(current) || freezing(current);
+ return fatal_signal_pending(current) || freezing(current) ||
+ (READ_ONCE(current->jobctl) & JOBCTL_TRAP_FREEZE);
}
static void wait_for_dump_helpers(struct file *file)
diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
index e039e29cd8c5..3835fbf7d80f 100644
--- a/include/linux/sched/signal.h
+++ b/include/linux/sched/signal.h
@@ -384,6 +384,13 @@ 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));
+}
+
+bool coredump_signal_pending(struct task_struct *p);
+
static inline int signal_pending(struct task_struct *p)
{
/*
@@ -393,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 or the freezer. */
+ if (unlikely(READ_ONCE(p->flags) & PF_DUMPCORE))
+ return coredump_signal_pending(p);
+ return 1;
}
static inline int fatal_signal_pending(struct task_struct *p)
diff --git a/kernel/signal.c b/kernel/signal.c
index ec30550951ec..d8bb1f168055 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -717,6 +717,14 @@ void signal_wake_up_state(struct task_struct *t, unsigned int state)
kick_process(t);
}
+/* Only SIGKILL or a freezer interrupt a coredump, see dump_interrupted(). */
+bool coredump_signal_pending(struct task_struct *p)
+{
+ return __fatal_signal_pending(p) || freezing(p) ||
+ (READ_ONCE(p->jobctl) & JOBCTL_TRAP_FREEZE);
+}
+EXPORT_SYMBOL(coredump_signal_pending);
+
static inline void posixtimer_sig_ignore(struct task_struct *tsk, struct sigqueue *q);
static void sigqueue_free_ignored(struct task_struct *tsk, struct sigqueue *q)
--
2.53.0
next prev parent reply other threads:[~2026-09-21 13:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 13:44 [PATCH v3 00/17] coredump & signals: an impossible affair Christian Brauner
2026-09-21 13:44 ` [PATCH v3 01/17] coredump: hold RCU while releasing parked threads Christian Brauner
2026-09-21 13:44 ` Christian Brauner [this message]
2026-09-22 12:55 ` [PATCH v3 02/17] signal: only SIGKILL and the freezers interrupt a coredumping task Oleg Nesterov
2026-09-22 14:33 ` Christian Brauner
2026-09-21 13:44 ` [PATCH v3 03/17] coredump: parse a snapshot of core_pattern Christian Brauner
2026-09-21 13:44 ` [PATCH v3 04/17] io-wq: order the exit bit against worker creation task work Christian Brauner
2026-09-21 13:44 ` [PATCH v3 05/17] signal: don't retarget shared signals in a dying thread group Christian Brauner
2026-09-21 13:44 ` [PATCH v3 06/17] selftests/coredump: test shared signal retargeting during a dump Christian Brauner
2026-09-21 13:44 ` [PATCH v3 07/17] fork: release the files of a failed fork after sched_cancel_fork() Christian Brauner
2026-09-21 13:44 ` [PATCH v3 08/17] exit: hang up the tty before closing the files Christian Brauner
2026-09-24 12:10 ` Oleg Nesterov
2026-09-21 13:44 ` [PATCH v3 09/17] ptrace: refuse to change the signal mask of a user worker Christian Brauner
2026-09-21 14:14 ` Oleg Nesterov
2026-09-21 13:44 ` [PATCH v3 10/17] selftests/coredump: test a user worker as the coredumping thread Christian Brauner
2026-09-21 13:45 ` [PATCH v3 11/17] selftests/coredump: expect PTRACE_SETSIGMASK to be refused on a user worker Christian Brauner
2026-09-21 13:45 ` [PATCH v3 12/17] exec: cancel io_uring requests before de_thread() Christian Brauner
2026-09-21 14:14 ` Oleg Nesterov
2026-09-24 14:19 ` Jens Axboe
2026-09-21 13:45 ` [PATCH v3 13/17] fork: move the coredump and exec checks into create_io_thread() Christian Brauner
2026-09-21 14:15 ` Oleg Nesterov
2026-09-21 13:45 ` [PATCH v3 14/17] fork: don't create io threads once PF_POSTCOREDUMP is set Christian Brauner
2026-09-21 14:26 ` Oleg Nesterov
2026-09-21 13:45 ` [PATCH v3 15/17] fork: use SIG_KERNEL_ONLY_MASK for the user worker signal mask Christian Brauner
2026-09-21 14:29 ` Oleg Nesterov
2026-09-21 13:45 ` [PATCH v3 16/17] signal: enforce the user worker signal mask in __set_task_blocked() Christian Brauner
2026-09-21 16:16 ` Oleg Nesterov
2026-09-21 20:05 ` Christian Brauner
2026-09-21 13:45 ` [PATCH v3 17/17] fs: close files from the highest descriptor down Christian Brauner
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=20260921-work-coredump-fixes-v3-2-8e4adb1619e6@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=mason@kernel.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