[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878tnkpv8h.fsf_-_@xmission.com>
Date: Sat, 01 Apr 2017 00:11:58 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Aleksa Sarai <asarai@...e.com>,
Andy Lutomirski <luto@...capital.net>,
Attila Fazekas <afazekas@...hat.com>,
Jann Horn <jann@...jh.net>, Kees Cook <keescook@...omium.org>,
Michal Hocko <mhocko@...nel.org>,
Ulrich Obergfell <uobergfe@...hat.com>,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: [RFC][PATCH 0/2] exec: Fixing ptrace'd mulit-threaded hang
I spent a little more time with this and only waiting until the killed
thread are zombies (and not reaped as we do today) really looks like
the right fix.
Oleg the following two patches work on top of your PTRACE_EVENT_EXIT
change and probably need a little more cleanup until they are ready
for serious posting.
That said I want to I want to post the code so I have a change at
some feedback before I prepare the final round of patches.
These patches only handle the case when sighand_struct is not
shared between different multi-threaded processes. The general
case is solvable but that is a quite a bit more code.
Eric W. Biederman (2):
sighand: Count each thread group once in sighand_struct
exec: If possible don't wait for ptraced threads to be reaped
fs/exec.c | 15 ++++++++++-----
include/linux/sched/signal.h | 2 +-
kernel/exit.c | 15 ++++++++++-----
kernel/fork.c | 6 ++++--
kernel/signal.c | 8 ++++++--
5 files changed, 31 insertions(+), 15 deletions(-)
Eric
Powered by blists - more mailing lists