public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Ni, BaoleX" <baolex.ni@intel.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"acme@kernel.org" <acme@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"alexander.shishkin@linux.intel.com" 
	<alexander.shishkin@linux.intel.com>,
	"Liu, Chuansheng" <chuansheng.liu@intel.com>
Subject: Re: hit a KASan bug related to Perf during stress test
Date: Mon, 24 Oct 2016 15:25:55 +0200	[thread overview]
Message-ID: <20161024132555.GA18410@redhat.com> (raw)
In-Reply-To: <20161024123814.GP3102@twins.programming.kicks-ass.net>

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);
 }
 
 /*

  reply	other threads:[~2016-10-24 13:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <318B87A793BE164187D8851D6CE09D64371C8811@shsmsx102.ccr.corp.intel.com>
2016-10-24  9:53 ` hit a KASan bug related to Perf during stress test Peter Zijlstra
2016-10-24 11:15   ` Oleg Nesterov
2016-10-24 11:24     ` Peter Zijlstra
2016-10-24 12:02       ` Oleg Nesterov
2016-10-24 12:10         ` Oleg Nesterov
2016-10-24 12:22           ` Peter Zijlstra
2016-10-24 12:29             ` Oleg Nesterov
2016-10-24 12:38               ` Peter Zijlstra
2016-10-24 13:25                 ` Oleg Nesterov [this message]
2016-10-24 13:40                   ` Oleg Nesterov
2016-10-24 14:17                     ` Peter Zijlstra
2016-10-24 14:36                   ` Peter Zijlstra
2016-10-24 15:39                     ` Oleg Nesterov
2016-10-24 15:53                       ` Oleg Nesterov
2016-10-25  6:55                         ` Ni, BaoleX
2016-10-25  9:28                       ` Peter Zijlstra
2016-10-25 14:41                         ` Oleg Nesterov
2016-10-26  9:03                           ` Peter Zijlstra
2016-10-26 16:10                             ` Oleg Nesterov
2016-10-24 12:19         ` Peter Zijlstra
2016-10-24 11:27     ` Peter Zijlstra
2016-10-24 11:29       ` Peter Zijlstra
2016-10-24 12:04         ` Jiri Olsa
2016-10-24 12:12           ` Peter Zijlstra
2016-10-24 12:11     ` Peter Zijlstra
2016-10-24 12:21       ` Oleg Nesterov
2016-10-24 12:27         ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161024132555.GA18410@redhat.com \
    --to=oleg@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=baolex.ni@intel.com \
    --cc=chuansheng.liu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox