[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wh128U4GxVeHa+z_5sB52ZVXhzt0__LQq4asZgh8VtvBw@mail.gmail.com>
Date: Tue, 4 Dec 2018 11:33:46 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: mhocko@...nel.org
Cc: Ingo Molnar <mingo@...nel.org>, pavel@....cz,
Oleg Nesterov <oleg@...hat.com>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
rafael.j.wysocki@...el.com, chanho.min@....com,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)
On Tue, Dec 4, 2018 at 10:17 AM Michal Hocko <mhocko@...nel.org> wrote:
>
> > How about something like we set PF_NOFREEZE when we set PF_EXITING? At
> > that point we've pretty much turned into a kernel thread, no?
>
> Hmm, that doesn't sound like a bad idea but I am not sure it will
> help because those threads we are waiting for might be block way before
> they reached PF_EXITING.
Yeah, looks that way. We've got the whole "zap_other_threads() ->
actually starting the exit" window, which is probably much bigger than
the "start the exit -> release_task" window.
So we'd have to mark things non-freezable at zap time, not at exit
time, and that's a lot more questionable.
Looking at this, I'm agreeing that ot would be better to just try to
narrow down the cred_guard_mutex use a lot.
Oleg, if you had patch that got push-back for that, maybe this problem
is now the impetus for people to say "yeah, that's not nice but we
clearly need to do it".
I'm not finding any old emails on this, but considering I redid my
email setup recently, that doesn't necessarily mean much.
Linus
Powered by blists - more mailing lists