[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170821191843.yb7cquiw37ktdvfm@hirez.programming.kicks-ass.net>
Date: Mon, 21 Aug 2017 21:18:43 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
Troy Kensinger <tkensinger@...gle.com>,
"security@...nel.org" <security@...nel.org>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Josh Triplett <josh@...htriplett.org>,
linux-kernel@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: perf_event_pid() (Was: [PATCH] pids: make task_tgid_nr_ns() safe)
On Mon, Aug 21, 2017 at 05:36:27PM +0200, Oleg Nesterov wrote:
> On 08/21, Oleg Nesterov wrote:
> >
> > This was reported many times, and this was even mentioned in commit
> > 52ee2dfdd4f5 "pids: refactor vnr/nr_ns helpers to make them safe" but
> > somehow nobody bothered to fix the obvious problem: task_tgid_nr_ns()
> > is not safe because task->group_leader points to nowhere after the
> > exiting task passes exit_notify(), rcu_read_lock() can not help.
>
> Peter,
>
> we already discussed this before, but I can't recall the result...
>
> perf_event_pid() can hit this problem too, with this patch the problem
> goes away but (with or without this patch) we do not want to report zero
> pids to avoid the confusion with idle threads, right?
>
> So do you think the patch below makes sense or we do not care?
Yeah, works for me. While rare I think it makes sense to distinguish
between a recently dead and the idle tasks.
Powered by blists - more mailing lists