Re: [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression
From: Linus Torvalds
Date: Sat May 27 2023 - 12:12:56 EST
On Sat, May 27, 2023 at 2:49 AM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>
> The real sticky widget for me is how to handle one of these processes
> coredumping. It really looks like it will result in a reliable hang.
Well, if *that* is the main worry, I think that's trivial enough to deal with.
In particular, we could make the rule just be that user worker threads
simply do not participate in core-dumps.
THAT isn't hard.
All we need to do is
(a) not count those threads in zap_threads()
(b) make sure that they don't add themselves to the "dumper" list by
not calling "coredujmp_task_exit()"
(c) not initiate core-dumping themselves.
and I think that's pretty much it.
In fact, that really seems like a good model *regardless*, because
honestly, a PF_IO_WORKER doesn't have valid register state for the
core dump anyway, and anything that would have caused a IO thread to
get a SIGSEGV *should* have caused a kernel oops already.
So the only worry is that the core dump will now happen while an IO
worker is still busy and so it's not "atomic" wrt possible VM changes,
but while that used to be a big problem back in the dark ages when we
didn't get the VM locks for core dumping, that got fixed a few years
ago because it already caused lots of potential issues.
End result: I think the attached patch is probably missing something,
but the approach "FeelsRight(tm)" to me.
Comments?
Linus
fs/coredump.c | 2 +-
kernel/exit.c | 6 ++++++
kernel/signal.c | 18 ++++++++++--------
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index ece7badf701b..46f8145b39e6 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -368,7 +368,7 @@ static int zap_process(struct task_struct *start, int exit_code)
for_each_thread(start, t) {
task_clear_jobctl_pending(t, JOBCTL_PENDING_MASK);
- if (t != current && !(t->flags & PF_POSTCOREDUMP)) {
+ if (t != current && !(t->flags & (PF_POSTCOREDUMP | PF_IO_WORKER))) {
sigaddset(&t->pending.signal, SIGKILL);
signal_wake_up(t, 1);
nr++;
diff --git a/kernel/exit.c b/kernel/exit.c
index 34b90e2e7cf7..fde57b9f4494 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -400,6 +400,12 @@ static void coredump_task_exit(struct task_struct *tsk)
{
struct core_state *core_state;
+ /*
+ * IO workers do not participate in dumping core
+ */
+ if (tsk->flags & PF_IO_WORKER)
+ return;
+
/*
* Serialize with any possible pending coredump.
* We must hold siglock around checking core_state
diff --git a/kernel/signal.c b/kernel/signal.c
index 8f6330f0e9ca..e0acb11d3a1d 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2845,6 +2845,16 @@ bool get_signal(struct ksignal *ksig)
*/
current->flags |= PF_SIGNALED;
+ /*
+ * PF_IO_WORKER threads will catch and exit on fatal signals
+ * themselves and do not participate in core dumping.
+ *
+ * They have cleanup that must be performed, so we cannot
+ * call do_exit() on their behalf.
+ */
+ if (current->flags & PF_IO_WORKER)
+ goto out;
+
if (sig_kernel_coredump(signr)) {
if (print_fatal_signals)
print_fatal_signal(ksig->info.si_signo);
@@ -2860,14 +2870,6 @@ bool get_signal(struct ksignal *ksig)
do_coredump(&ksig->info);
}
- /*
- * PF_IO_WORKER threads will catch and exit on fatal signals
- * themselves. They have cleanup that must be performed, so
- * we cannot call do_exit() on their behalf.
- */
- if (current->flags & PF_IO_WORKER)
- goto out;
-
/*
* Death signals, no core dump.
*/