Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754906AbcJZQMP (ORCPT ); Wed, 26 Oct 2016 12:12:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41160 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752496AbcJZQMO (ORCPT ); Wed, 26 Oct 2016 12:12:14 -0400 Date: Wed, 26 Oct 2016 18:10:39 +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: <20161026161038.GB28832@redhat.com> References: <20161024121030.GA17007@redhat.com> <20161024122210.GM3102@twins.programming.kicks-ass.net> <20161024122942.GC17007@redhat.com> <20161024123814.GP3102@twins.programming.kicks-ass.net> <20161024132555.GA18410@redhat.com> <20161024143646.GR3102@twins.programming.kicks-ass.net> <20161024153908.GA26135@redhat.com> <20161025092831.GW3102@twins.programming.kicks-ass.net> <20161025144126.GD4326@redhat.com> <20161026090332.GA3102@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161026090332.GA3102@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.26]); Wed, 26 Oct 2016 16:12:13 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1635 Lines: 55 On 10/26, Peter Zijlstra wrote: > > On Tue, Oct 25, 2016 at 04:41:26PM +0200, Oleg Nesterov wrote: > > > > > > So what serialization would close that race? __task_pid_nr_ns() only > > > seems to use RCU nothing more. > > > > I do not see how can we close this race, we obviously do not want to use > > any locking. > > > > That is why I tried to suggest > > > > nr = __task_pid_nr_ns(p, type, event->ns); > > if (!nr && !is_idle_task(p)) > > nr = -1; > > return nr; > > > > but this will report -1 if p runs in another namespace, so perhaps we > > can do > > > > nr = __task_pid_nr_ns(p, type, event->ns); > > if (!nr && p->exit_state) > > // it has already called exit_notify > > nr = -1; > > return nr; > > I think I'm asking how __task_pid_nr_ns() isn't susceptible to this race > ;-) which race ? ;) it seems that I confused you. Lets ignore the original problem with perf_event_pid()->task_tgid_nr_ns() which can access the freed memory. Lets suppose it is already fixed. Another problem, as you noted, is that task_tgid_nr_ns/task_pid_nr_ns returns zero if the task exits and this zero can be confused with the swapper's pid. return pid_alive(p) ? task_pid_nr_ns(p, event->ns) : ~0 still can return zero because pid_alive(p) == T is not stable if we can race with the exiting task, so it can't guarantee that task_pid_nr_ns() won't return 0. So we can check ->exit_state or, even better, that same pid_alive() after task_pid_nr_ns() returns 0. nr = task_pid_nr_ns(p); /* avoid -1 if it is idle thread or runs in another ns */ if (!nr && !pid_alive(p)) nr = -1; return nr; Or I misunderstood you? Oleg.