[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjXxM0VnLN6iwVeORwxED5QgXS_AXUJ4+Af3jUeFY21gw@mail.gmail.com>
Date: Sat, 11 Apr 2020 13:07:48 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bernd Edlinger <bernd.edlinger@...mail.de>
Cc: Oleg Nesterov <oleg@...hat.com>,
"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>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Sat, Apr 11, 2020 at 12:15 PM Bernd Edlinger
<bernd.edlinger@...mail.de> wrote:
>
> But won't the dead thread's lifetime overlap the new thread's lifetime
> from the tracer's POV?
What new thread?
execve() doesn't create any new thread.
But yes, an external tracer could see the (old) thread that did
execve() do new system calls before it sees the (other old) thread
that was a zombie.
But that is already somethign that can happen, simply because the
events aren't ordered. The whole issue is that the zombie thread
already died, but the tracer just didn't bother to read that state
change.
So it's not that the dead thread somehow _dies_ after the execve(). It
already died.
It's just that whoever is to reap it (or traces it) just hasn't cared
to read the status of that thing yet.
Linus
Powered by blists - more mailing lists