lkml.org 
[lkml]   [2019]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: WARNING in event_function_local
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.

\
 
 \ /
  Last update: 2019-02-13 10:58    [W:0.041 / U:1.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site