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.
