diff options
author | Eric W. Biederman <[email protected]> | 2012-06-20 12:53:03 -0700 |
---|---|---|
committer | Linus Torvalds <[email protected]> | 2012-06-20 14:39:36 -0700 |
commit | 6347e90091041e34bea625370794c92f4ce71228 (patch) | |
tree | 20614d4eedd2993248be3c3562177c7e00f24b68 /tools/perf/util/scripting-engines/trace-event-python.c | |
parent | f39cdaebb89dc3e6dd4f3e75b6d4e87ef12190af (diff) |
pidns: guarantee that the pidns init will be the last pidns process reaped
Today we have a twofold bug. Sometimes release_task on pid == 1 in a pid
namespace can run before other processes in a pid namespace have had
release task called. With the result that pid_ns_release_proc can be
called before the last proc_flus_task() is done using upid->ns->proc_mnt,
resulting in the use of a stale pointer. This same set of circumstances
can lead to waitpid(...) returning for a processes started with
clone(CLONE_NEWPID) before the every process in the pid namespace has
actually exited.
To fix this modify zap_pid_ns_processess wait until all other processes in
the pid namespace have exited, even EXIT_DEAD zombies.
The delay_group_leader and related tests ensure that the thread gruop
leader will be the last thread of a process group to be reaped, or to
become EXIT_DEAD and self reap. With the change to zap_pid_ns_processes
we get the guarantee that pid == 1 in a pid namespace will be the last
task that release_task is called on.
With pid == 1 being the last task to pass through release_task
pid_ns_release_proc can no longer be called too early nor can wait return
before all of the EXIT_DEAD tasks in a pid namespace have exited.
Signed-off-by: Eric W. Biederman <[email protected]>
Signed-off-by: Oleg Nesterov <[email protected]>
Cc: Louis Rilling <[email protected]>
Cc: Mike Galbraith <[email protected]>
Acked-by: Pavel Emelyanov <[email protected]>
Tested-by: Andrew Wagin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/util/scripting-engines/trace-event-python.c')
0 files changed, 0 insertions, 0 deletions