From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757452AbcJXL3x (ORCPT ); Mon, 24 Oct 2016 07:29:53 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:39983 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757421AbcJXL3q (ORCPT ); Mon, 24 Oct 2016 07:29:46 -0400 Date: Mon, 24 Oct 2016 13:29:45 +0200 From: Peter Zijlstra To: Oleg Nesterov Cc: "Ni, BaoleX" , "mingo@redhat.com" , "acme@kernel.org" , "linux-kernel@vger.kernel.org" , "alexander.shishkin@linux.intel.com" , "Liu, Chuansheng" , Jiri Olsa Subject: Re: hit a KASan bug related to Perf during stress test Message-ID: <20161024112945.GI3157@twins.programming.kicks-ass.net> References: <318B87A793BE164187D8851D6CE09D64371C8811@shsmsx102.ccr.corp.intel.com> <20161024095341.GF3102@twins.programming.kicks-ass.net> <20161024111526.GA13509@redhat.com> <20161024112732.GJ3102@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161024112732.GJ3102@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 24, 2016 at 01:27:32PM +0200, Peter Zijlstra wrote: > On Mon, Oct 24, 2016 at 01:15:27PM +0200, Oleg Nesterov wrote: > > How about the trivial fix below? > > > > Oleg. > > > > --- x/kernel/events/core.c > > +++ x/kernel/events/core.c > > @@ -1257,7 +1257,7 @@ static u32 perf_event_pid(struct perf_ev > > if (event->parent) > > event = event->parent; > > > > - return task_tgid_nr_ns(p, event->ns); > > + return pid_alive(p) ? task_tgid_nr_ns(p, event->ns) : 0; > > } > > Also, now we get a (few) sample(s) with a different pid:tid than prior > samples and not matching the sched_switch() events. > > I can imagine that being somewhat confusing for people/tools. > > Acme/Jolsa, any idea if that will bugger perf-report? Hurm, then again, I imagine that after unhash_process the PID/TID could be instantly re-used and then we're still confused. Yuck.