Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S940962AbcJXN1a (ORCPT ); Mon, 24 Oct 2016 09:27:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54544 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937716AbcJXN12 (ORCPT ); Mon, 24 Oct 2016 09:27:28 -0400 Date: Mon, 24 Oct 2016 15:25:55 +0200 From: Oleg Nesterov To: Peter Zijlstra Cc: "Ni, BaoleX" , "mingo@redhat.com" , "acme@kernel.org" , "linux-kernel@vger.kernel.org" , "alexander.shishkin@linux.intel.com" , "Liu, Chuansheng" Subject: Re: hit a KASan bug related to Perf during stress test Message-ID: <20161024132555.GA18410@redhat.com> References: <318B87A793BE164187D8851D6CE09D64371C8811@shsmsx102.ccr.corp.intel.com> <20161024095341.GF3102@twins.programming.kicks-ass.net> <20161024111526.GA13509@redhat.com> <20161024112402.GI3102@twins.programming.kicks-ass.net> <20161024120231.GA16554@redhat.com> <20161024121030.GA17007@redhat.com> <20161024122210.GM3102@twins.programming.kicks-ass.net> <20161024122942.GC17007@redhat.com> <20161024123814.GP3102@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161024123814.GP3102@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 24 Oct 2016 13:27:28 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2389 Lines: 80 On 10/24, Peter Zijlstra wrote: > > On Mon, Oct 24, 2016 at 02:29:42PM +0200, Oleg Nesterov wrote: > > On 10/24, Peter Zijlstra wrote: > > > > > > Still, I wonder if returning 0 is the right thing. 0 is a 'valid' PID > > > for the init/idle task. > > > > Yes, now I think that -1 would make more sense. Unfortunately we can't > > just change __task_pid_nr_ns(), it already has the users which assume > > it returns zero... attach_to_pi_state() for example. > > Indeed. And I have a patch that assumes task_pid_vnr(&init_task) == 0, > is that true because of this !alive case or true in general? This is true in general. Idle threads are always alive but they use the the special init_struct_pid with .nr == 0. > No worries though, we can revert to your earlier explicit test and > return -1 while adding a comment to explain details? ... > Ah, ok. So whould we change that to match pid and return (explicit) -1 > there too? Well, if we add that PIDTYPE_TGID hack, I think we can do something like below... Or do you think we should add a perf_alive() check into perf_event_pid() for a quick fix? Either way it's a pity we can't report at least the valid tid, perhaps perf_event_tid() could use task_pid_nr() if event->ns == init_pid_ns, I dunno. Oleg. --- x/kernel/events/core.c +++ x/kernel/events/core.c @@ -1249,26 +1249,30 @@ unclone_ctx(struct perf_event_context *c return parent_ctx; } -static u32 perf_event_pid(struct perf_event *event, struct task_struct *p) +static u32 perf_event_xxx(struct perf_event *event, struct task_struct *p, + enum pid_type type) { + pid_t nr; /* * only top level events have the pid namespace they were created in */ if (event->parent) event = event->parent; - return task_tgid_nr_ns(p, event->ns); + nr = __task_pid_nr_ns(p, type, event->ns); + if (!nr && !is_idle_task(p)) + nr = -1; + return nr; } -static u32 perf_event_tid(struct perf_event *event, struct task_struct *p) +static u32 perf_event_pid(struct perf_event *event, struct task_struct *p) { - /* - * only top level events have the pid namespace they were created in - */ - if (event->parent) - event = event->parent; + return perf_event_xxx(p, event, PIDTYPE_TGID); +} - return task_pid_nr_ns(p, event->ns); +static u32 perf_event_tid(struct perf_event *event, struct task_struct *p) +{ + return perf_event_xxx(p, event, PIDTYPE_PID); } /*