[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whJ8khGBqfqh6ZmHsKjcyyBLm5xgkgLW_AC_=82iFBWoQ@mail.gmail.com>
Date: Thu, 9 Apr 2020 12:42:00 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bernd Edlinger <bernd.edlinger@...mail.de>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Waiman Long <longman@...hat.com>,
Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alexey Gladkov <gladkov.alexey@...il.com>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Thu, Apr 9, 2020 at 11:36 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I guess I need to look at what that test is actually testing, because
> it wasn't what I thought.
Ahh.
The problem is that zap_other_threads() counts all threads.
But it doesn't bother notifying already dead threads, even if it counts them.
And then it waits for the threads to go away, but didn't do anything
to make that dead thread go away.
And the test case has an already dead thread that is just waiting to
be reaped by the same person who is now waiting for it to go away.
So it just stays around.
Honestly, I'm not entirely sure this is worth worrying about, since
it's all killable anyway and only happens if you do something stupid.
I mean, you can get two threads to wait for each other more easily other ways.
Or maybe we just shouldn't count already dead threads? Yeah, they'd
share that current signal struct, but they're dead and can't do
anything about it, they can only be reaped.
But that would mean that we should also move the signal->notify_count
update to when we mark the EXIT_ZOMBIE or EXIT_DEAD in exit_state.
Linus
Powered by blists - more mailing lists