From: Jiri Olsa <jolsa@redhat.com>
To: Borislav Petkov <bp@alien8.de>,
Namhyung Kim <namhyung@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
lkml <linux-kernel@vger.kernel.org>,
Stephane Eranian <eranian@google.com>,
Namhyung Kim <namhyung.kim@lge.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: BUG: using smp_processor_id() in preemptible [00000000] code: asm/8267
Date: Wed, 27 Mar 2013 11:42:56 +0100 [thread overview]
Message-ID: <20130327104256.GB1092@krava.brq.redhat.com> (raw)
In-Reply-To: <20130327094932.GA8385@pd.tnic>
On Wed, Mar 27, 2013 at 10:49:32AM +0100, Borislav Petkov wrote:
> On Wed, Mar 27, 2013 at 03:02:10PM +0900, Namhyung Kim wrote:
> > > --
> > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > index 7b4a55d41efc..f3bb3384a106 100644
> > > --- a/kernel/events/core.c
> > > +++ b/kernel/events/core.c
> > > @@ -4455,8 +4455,11 @@ static void perf_event_task_event(struct perf_task_event *task_event)
> > > next:
> > > put_cpu_ptr(pmu->pmu_cpu_context);
> > > }
> > > +
> > > + preempt_disable();
> > > if (task_event->task_ctx)
> > > perf_event_task_ctx(task_event->task_ctx, task_event);
> > > + preempt_enable();
>
> Ok, just for my own understanding: how do the events on the
> ->task_ctx->event_list relate to the current cpu in this path? I mean,
> we're on the task exit path here so is it possible to be rescheduled
> somewhere else and the check in event_filter_match to become
> meaningless?
>
> Because with this fix, we have a small window between enabling
> preemption after the last pmu context and disabling it again to get
> moved somewhere else.
hm, at that point we have 'task_event->task_ctx' detached from
the task and all events on it are owned by the task
so I wonder maybe we could eliminate the preempt switch and make
a special case for task context, saying all event match for it,
something like in patch below (untested)
because if we keep the check we could endup with no EXIT event,
just because the exit code was scheduled on another cpu
(for task events with specified cpu)
also that's probably what we want to do in here - send EXIT
event for any task event that asked for it
the output code in perf_event_task_output is guarding
the preemption by itself
jirka
---
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 7b4a55d..8414bcf 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4403,12 +4403,12 @@ out:
task_event->event_id.header.size = size;
}
-static int perf_event_task_match(struct perf_event *event)
+static int perf_event_task_match(struct perf_event *event, int match)
{
if (event->state < PERF_EVENT_STATE_INACTIVE)
return 0;
- if (!event_filter_match(event))
+ if (!match && !event_filter_match(event))
return 0;
if (event->attr.comm || event->attr.mmap ||
@@ -4419,12 +4419,13 @@ static int perf_event_task_match(struct perf_event *event)
}
static void perf_event_task_ctx(struct perf_event_context *ctx,
- struct perf_task_event *task_event)
+ struct perf_task_event *task_event,
+ int match)
{
struct perf_event *event;
list_for_each_entry_rcu(event, &ctx->event_list, event_entry) {
- if (perf_event_task_match(event))
+ if (perf_event_task_match(event, match))
perf_event_task_output(event, task_event);
}
}
@@ -4441,7 +4442,7 @@ static void perf_event_task_event(struct perf_task_event *task_event)
cpuctx = get_cpu_ptr(pmu->pmu_cpu_context);
if (cpuctx->unique_pmu != pmu)
goto next;
- perf_event_task_ctx(&cpuctx->ctx, task_event);
+ perf_event_task_ctx(&cpuctx->ctx, task_event, 0);
ctx = task_event->task_ctx;
if (!ctx) {
@@ -4450,13 +4451,13 @@ static void perf_event_task_event(struct perf_task_event *task_event)
goto next;
ctx = rcu_dereference(current->perf_event_ctxp[ctxn]);
if (ctx)
- perf_event_task_ctx(ctx, task_event);
+ perf_event_task_ctx(ctx, task_event, 0);
}
next:
put_cpu_ptr(pmu->pmu_cpu_context);
}
if (task_event->task_ctx)
- perf_event_task_ctx(task_event->task_ctx, task_event);
+ perf_event_task_ctx(task_event->task_ctx, task_event, 1);
rcu_read_unlock();
}
next prev parent reply other threads:[~2013-03-27 10:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-24 11:55 Borislav Petkov
2013-03-24 15:59 ` Borislav Petkov
2013-03-26 18:34 ` Borislav Petkov
2013-03-27 6:02 ` Namhyung Kim
2013-03-27 9:49 ` Borislav Petkov
2013-03-27 10:42 ` Jiri Olsa [this message]
2013-03-27 14:09 ` Peter Zijlstra
2013-03-27 16:31 ` Borislav Petkov
2013-04-30 15:27 ` [RFCv2] " Jiri Olsa
2013-03-27 13:15 ` Joerg Roedel
2013-03-27 14:17 ` Peter Zijlstra
2013-03-27 14:37 ` Paul E. McKenney
2013-03-27 16:34 ` Joerg Roedel
2013-03-27 16:38 ` Borislav Petkov
2013-03-27 18:04 ` Paul E. McKenney
2013-03-27 19:07 ` Borislav Petkov
2013-03-27 19:20 ` Borislav Petkov
2013-03-27 19:22 ` Paul E. McKenney
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=20130327104256.GB1092@krava.brq.redhat.com \
--to=jolsa@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=bp@alien8.de \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung.kim@lge.com \
--cc=namhyung@kernel.org \
--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
all inboxes | Powered by JetHome®