On Wed, Feb 13, 2019 at 10:57:26AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 10:51:58AM +0100, Peter Zijlstra wrote:
> > On Tue, Feb 12, 2019 at 07:40:12PM -0800, Kees Cook wrote:
> >
> > > > > Is this maybe just an unlucky condition with the event loop running in
> > > > > an IRQ? Should the WARN be expected, or is running under an IRQ
> > > > > unexpected?
> > >
> > > Is perf expected to fire during an IRQ? The task == current test seems
> > > suspicious if so...
> >
> > So the only possible callchain here is:
> >
> > <PMI>
> > ...
> > perf_event_disable_inatomic()
> > irq_work_queue()
> >
> > <irq_work-IPI>
> > perf_pending_event()
> > perf_event_disable_local()
> > event_function_local()
> >
> >
> > The assertion states that:
> >
> > if the event is a task event; and the context is active, it _must_ be
> > the same task.
> >
> > Because: if the PMI happens during ctxsw (which has IRQs disabled), the
> > IPI will not happen until after the ctxsw, at which point we'll also
> > have switched out the perf context of that task -- IOW the context
> > should be inactive.
> >
> >
> > Anyway, it looks like a virt issue; I'll start caring once you can
> > reproduce on real hardware.
>
> Hurm.. I might have spoken too soon. I still don't give a crap about
> virt, but I think I might see an actual problem.
>
> The moment we re-enable IRQs after ctxsw, the task can already be
> running on another CPU, and _that_ would trigger failure here.
>
> Let me think a little about that.
Humm, but in that case:
context_switch()
prepare_task_switch()
perf_event_task_sched_out()
__perf_event_task_sched_out()
perf_event_context_sched_out()
task_ctx_sched_out()
ctx_sched_out()
group_sched_out()
event_sched_out()
if (event->pending_disable)
Would have already cleared the pending_disable state, so the IPI would
not have ran perf_event_disable_local() in the first place.
