linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>, Pavel Machek <pavel@ucw.cz>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Linux PM <linux-pm@vger.kernel.org>
Subject: Re: [RFC][PATCH] exec: Conceal the other threads from wakeups during exec
Date: Thu, 30 Jul 2020 16:17:50 -0700	[thread overview]
Message-ID: <CAHk-=wjMcHGDh8Wx+dwaYHOGVNN+zzCPEKZEc5qb3spsEydNKg@mail.gmail.com> (raw)
In-Reply-To: <87pn8c1uj6.fsf_-_@x220.int.ebiederm.org>

On Thu, Jul 30, 2020 at 4:00 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> The key is the function make_task_wakekill which could probably
> benefit from a little more review and refinement but appears to
> be basically correct.

You really need to explain a lot more why you think this is all a good idea.

For example, what if one of those other threads is waiting in line for
a critical lock, and the wait-queue you basically disabled was the
exclusive wait after lock handoff?

That means that the lock will now effectively be held by that thread.
No, it wasn't woken up, but it had the lock handed to it, and it's now
entirely unresponsive until it is killed.

How is that different from the deadlocks you're actually trying to fix?

These are the kinds of problems that the freezer() code had too, with
freezing things that held locks etc.

This approach does seem better than the freezer thing, and if I read
it right it will gather things in the signal handler code, but it's
not obvious that gathering them in random places where they sleep for
random reasons is safe or a good idea.

I can imagine _so_ many dead systems if you just basically froze
something that holds the mmap lock and is sleeping on a page fault,
for example.

Maybe I'm missing something, but I really think your "let's freeze
things" is seriously misguided. You're concentrating on some small
problem and trying to solve that, and not seeign the HUGE HONKING
problems that your approach is fundamentally introducing.

              Linus

  reply	other threads:[~2020-07-30 23:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 21:03 [RFC][PATCH] exec: Freeze the other threads during a multi-threaded exec Eric W. Biederman
2020-07-28  0:20 ` Linus Torvalds
2020-07-28 12:39   ` Eric W. Biederman
2020-07-28 13:20     ` Eric W. Biederman
2020-07-28 18:17       ` Linus Torvalds
2020-07-30 13:16         ` Eric W. Biederman
2020-07-30 22:56           ` [RFC][PATCH] exec: Conceal the other threads from wakeups during exec Eric W. Biederman
2020-07-30 23:17             ` Linus Torvalds [this message]
2020-07-31 17:16               ` Eric W. Biederman
2020-07-31 17:41                 ` Linus Torvalds
2020-07-31 20:07                   ` Eric W. Biederman
2020-07-31  6:28             ` Oleg Nesterov
2020-07-31 16:50               ` Eric W. Biederman
2020-07-28  9:41 ` [RFC][PATCH] exec: Freeze the other threads during a multi-threaded exec Aleksa Sarai
2020-07-28 12:18   ` Eric W. Biederman

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='CAHk-=wjMcHGDh8Wx+dwaYHOGVNN+zzCPEKZEc5qb3spsEydNKg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    /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;
as well as URLs for NNTP newsgroup(s).