Re: WARN_ON_ONCE(in_nmi()) hit in irq_work_queue_on

[Peter Zijlstra]

On Wed, Aug 06, 2014 at 06:46:33PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 06, 2014 at 12:21:13PM -0400, Dave Jones wrote:
> > WARNING: CPU: 3 PID: 18062 at kernel/irq_work.c:72 irq_work_queue_on+0x11e/0x140()
> > CPU: 3 PID: 18062 Comm: trinity-subchil Not tainted 3.16.0+ #34
> >  0000000000000009 00000000903774d1 ffff880244e06c00 ffffffff9a7f1e37
> >  0000000000000000 ffff880244e06c38 ffffffff9a0791dd ffff880244fce180
> >  0000000000000003 ffff880244e06d58 ffff880244e06ef8 0000000000000000
> > Call Trace:
> >  <NMI>  [<ffffffff9a7f1e37>] dump_stack+0x4e/0x7a
> >  [<ffffffff9a0791dd>] warn_slowpath_common+0x7d/0xa0
> >  [<ffffffff9a07930a>] warn_slowpath_null+0x1a/0x20
> >  [<ffffffff9a17ca1e>] irq_work_queue_on+0x11e/0x140
> >  [<ffffffff9a10a2c7>] tick_nohz_full_kick_cpu+0x57/0x90
> >  [<ffffffff9a186cd5>] __perf_event_overflow+0x275/0x350
> >  [<ffffffff9a184f80>] ? perf_event_task_disable+0xa0/0xa0
> >  [<ffffffff9a01a4cf>] ? x86_perf_event_set_period+0xbf/0x150
> >  [<ffffffff9a187934>] perf_event_overflow+0x14/0x20
> >  [<ffffffff9a020386>] intel_pmu_handle_irq+0x206/0x410
> >  [<ffffffff9a0b54d3>] ? arch_vtime_task_switch+0x63/0x130
> >  [<ffffffff9a01937b>] perf_event_nmi_handler+0x2b/0x50
> >  [<ffffffff9a007b72>] nmi_handle+0xd2/0x390
> >  [<ffffffff9a007aa5>] ? nmi_handle+0x5/0x390
> >  [<ffffffff9a0d131b>] ? lock_release+0xab/0x330
> >  [<ffffffff9a008062>] default_do_nmi+0x72/0x1c0
> >  [<ffffffff9a0c925f>] ? cpuacct_account_field+0xcf/0x200
> >  [<ffffffff9a008268>] do_nmi+0xb8/0x100
> >  [<ffffffff9a7ff66a>] end_repeat_nmi+0x1e/0x2e
> >  [<ffffffff9a0c925f>] ? cpuacct_account_field+0xcf/0x200
> >  [<ffffffff9a0d131b>] ? lock_release+0xab/0x330
> >  [<ffffffff9a0d131b>] ? lock_release+0xab/0x330
> >  [<ffffffff9a0d131b>] ? lock_release+0xab/0x330
> >  <<EOE>>  [<ffffffff9a0c9277>] cpuacct_account_field+0xe7/0x200
> >  [<ffffffff9a0c9195>] ? cpuacct_account_field+0x5/0x200
> >  [<ffffffff9a0b4d18>] account_system_time+0x98/0x1a0
> >  [<ffffffff9a0b4e4e>] __vtime_account_system+0x2e/0x40
> >  [<ffffffff9a0b5419>] vtime_user_enter+0x59/0x90
> >  [<ffffffff9a18e183>] ? context_tracking_user_enter+0xd3/0x1f0
> >  [<ffffffff9a18e183>] context_tracking_user_enter+0xd3/0x1f0
> >  [<ffffffff9a013815>] syscall_trace_leave+0xa5/0x210
> >  [<ffffffff9a7fd8bf>] int_check_syscall_exit_work+0x34/0x3d
> > ---[ end trace 73831bdc3ef3ba75 ]---
> 
> Urgh, Frederic, any idea how that happened? 

Sigh, that's d84153d6c96f61a so that's been there a while, and been
broken equally long.

So this is where we run a low period (!freq) hardware event on a
nohz_full cpu or so? And because it throttles, we need to kick the tick
into action to unthrottle it.

I suppose there's a good reason I never build with that nohz_full
nonsense enabled :/

Not sure how we should go fix that, you can't just issue random IPIs
from NMI context.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/