[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiDwR+6ugYaKEGHfYteLF+NH5xu=T7uuUTkK9y-hr6zow@mail.gmail.com>
Date: Sun, 12 Apr 2020 13:14:04 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Bernd Edlinger <bernd.edlinger@...mail.de>,
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 Sun, Apr 12, 2020 at 12:51 PM Oleg Nesterov <oleg@...hat.com> wrote:
>
> To be honest, I don't understand it... OK, suppose that the main thread
> M execs and zap_other_threads() finds a single (and alive) sub-thread T,
> sig->notify_count = 1.
>
> If T is traced, then ->notify_count won't be decremented until the tracer
> reaps this task, so we have the same problem.
Right you are.
I was hoping to avoid the "move notify_count update", but you're
right, the threads that do get properly killed will never get to that
point, so now the live ones that we're waiting for will just hit the
same issue that the dead ones did.
Goot catch. So the optimistic simplification doesn't work.
> > You do say in that old patch that we can't just share the signal
> > state, but I wonder how true that is.
>
> We can share sighand_struct with TASK_ZOMBIE's. The problem is that
> we can not unshare ->sighand until they go away, execing thread and
> zombies must use the same sighand->siglock to serialize the access to
> ->thread_head/etc.
Yeah, they'll still touch the lock, and maybe look at it, but it's not
like they'll be changing any state.
> but see above, I don't think this makes any sense.
Yeah, I think your patch is better since my simplification doesn't work.
Linus
Powered by blists - more mailing lists