From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
Mike Christie <michael.christie@oracle.com>,
linux@leemhuis.info, nicolas.dichtel@6wind.com, axboe@kernel.dk,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, mst@redhat.com,
sgarzare@redhat.com, jasowang@redhat.com, stefanha@redhat.com,
brauner@kernel.org
Subject: Re: [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression
Date: Sat, 27 May 2023 20:17:09 -0500 [thread overview]
Message-ID: <87mt1pmezu.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <CAHk-=whsi9JFP-okH3jXHrA8rh8bMuuSt6ZgkmPwiDMAn437qA@mail.gmail.com> (Linus Torvalds's message of "Sat, 27 May 2023 09:12:27 -0700")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, May 27, 2023 at 2:49 AM Eric W. Biederman <ebiederm@xmission.com> 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?
It seems like a good approach for including in the -rc series.
I think the change should look more like my change below.
nits:
- The threads all need to participate in the group exit even if they
aren't going to be in the coredump.
- For vhost_worker we need s/PF_IO_WORKER/PF_USER_WORKER/.
- Moving PF_IO_WORKER above the sig_kernel_coredump(signr) test is
unnecessary. The sig_kernel_coredump(signr) test can only become
true if a process exit has not been initiated yet. More importantly
moving the test obscures the fact that only do_group_exit is
moved out of get_signal for the PF_IO_WORKER special case.
Long term I think we want an approach that stops the worker threads
during the coredumps. It will just yield a better quality of
implementation if we minimize the amount of concurrency during the
coredump.
I have a pending patchset that moves the coredump rendezvous into
get_signal. At which point stopping all of the threads is just like
SIGSTOP something the worker threads can use and it won't introduce any
issues. Today the problem is some of the worker thread code must run
before the coredump stop.
Looking forward I don't see not asking the worker threads to stop
for the coredump right now causing any problems in the future.
So I think we can use this to resolve the coredump issue I spotted.
diff --git a/fs/coredump.c b/fs/coredump.c
index ece7badf701b..620f7f9dc894 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -371,7 +371,8 @@ static int zap_process(struct task_struct *start, int exit_code)
if (t != current && !(t->flags & PF_POSTCOREDUMP)) {
sigaddset(&t->pending.signal, SIGKILL);
signal_wake_up(t, 1);
- nr++;
+ if (!(t->flags & PF_IO_WORKER))
+ nr++;
}
}
diff --git a/kernel/exit.c b/kernel/exit.c
index 34b90e2e7cf7..6082dba9131a 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -411,7 +411,9 @@ static void coredump_task_exit(struct task_struct *tsk)
tsk->flags |= PF_POSTCOREDUMP;
core_state = tsk->signal->core_state;
spin_unlock_irq(&tsk->sighand->siglock);
- if (core_state) {
+
+ /* I/O Workers don't participate in coredumps */
+ if (core_state && !(tsk->flags & PF_IO_WORKER) {
struct core_thread self;
self.task = current;
> 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.
> */
Eric
next prev parent reply other threads:[~2023-05-28 1:17 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 2:51 [PATCH 0/3] vhost: Fix freezer/ps regressions Mike Christie
2023-05-22 2:51 ` [PATCH 1/3] signal: Don't always put SIGKILL in shared_pending Mike Christie
2023-05-23 15:30 ` Eric W. Biederman
2023-05-22 2:51 ` [PATCH 2/3] signal: Don't exit for PF_USER_WORKER tasks Mike Christie
2023-05-22 2:51 ` [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression Mike Christie
2023-05-22 12:30 ` Oleg Nesterov
2023-05-22 17:00 ` Mike Christie
2023-05-22 17:47 ` Oleg Nesterov
2023-05-23 12:15 ` Oleg Nesterov
2023-05-23 15:57 ` Eric W. Biederman
2023-05-24 14:10 ` Oleg Nesterov
2023-05-24 14:44 ` Eric W. Biederman
2023-05-25 11:55 ` Oleg Nesterov
2023-05-25 15:30 ` Eric W. Biederman
2023-05-25 16:20 ` Linus Torvalds
2023-05-27 9:49 ` Eric W. Biederman
2023-05-27 16:12 ` Linus Torvalds
2023-05-28 1:17 ` Eric W. Biederman [this message]
2023-05-28 1:21 ` Linus Torvalds
2023-05-29 11:19 ` Oleg Nesterov
2023-05-29 16:09 ` michael.christie
2023-05-29 17:46 ` Oleg Nesterov
2023-05-29 17:54 ` Oleg Nesterov
2023-05-29 19:03 ` Mike Christie
2023-05-29 19:35 ` Mike Christie
2023-05-29 19:46 ` michael.christie
2023-05-30 2:48 ` Eric W. Biederman
2023-05-30 2:38 ` Eric W. Biederman
2023-05-30 15:34 ` Mike Christie
2023-05-31 3:30 ` Mike Christie
2023-05-29 16:11 ` michael.christie
2023-05-30 14:15 ` Christian Brauner
2023-05-30 17:55 ` Oleg Nesterov
2023-05-30 15:01 ` Eric W. Biederman
2023-05-31 5:22 ` Jason Wang
2023-05-24 0:02 ` Mike Christie
2023-05-25 16:15 ` Mike Christie
2023-05-28 1:41 ` Eric W. Biederman
2023-05-28 19:29 ` Mike Christie
2023-05-31 5:22 ` Jason Wang
2023-05-31 7:25 ` Oleg Nesterov
2023-05-31 8:17 ` Jason Wang
2023-05-31 9:14 ` Oleg Nesterov
2023-06-01 2:44 ` Jason Wang
2023-06-01 7:43 ` Oleg Nesterov
2023-06-02 5:03 ` Jason Wang
2023-06-02 17:58 ` Oleg Nesterov
2023-06-02 20:07 ` Linus Torvalds
2023-06-05 14:20 ` Oleg Nesterov
2023-05-22 19:40 ` Michael S. Tsirkin
2023-05-23 15:39 ` Eric W. Biederman
2023-05-23 15:48 ` Mike Christie
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=87mt1pmezu.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=michael.christie@oracle.com \
--cc=mst@redhat.com \
--cc=nicolas.dichtel@6wind.com \
--cc=oleg@redhat.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome