From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932689AbaHFQ4P (ORCPT ); Wed, 6 Aug 2014 12:56:15 -0400 Received: from casper.infradead.org ([85.118.1.10]:43451 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932465AbaHFQ4M convert rfc822-to-8bit (ORCPT ); Wed, 6 Aug 2014 12:56:12 -0400 Date: Wed, 6 Aug 2014 18:56:10 +0200 From: Peter Zijlstra To: Dave Jones , Linux Kernel Cc: Frederic Weisbecker Subject: Re: WARN_ON_ONCE(in_nmi()) hit in irq_work_queue_on Message-ID: <20140806165610.GB12054@laptop.lan> References: <20140806162113.GC14261@redhat.com> <20140806164633.GY3935@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20140806164633.GY3935@laptop> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > > [] dump_stack+0x4e/0x7a > > [] warn_slowpath_common+0x7d/0xa0 > > [] warn_slowpath_null+0x1a/0x20 > > [] irq_work_queue_on+0x11e/0x140 > > [] tick_nohz_full_kick_cpu+0x57/0x90 > > [] __perf_event_overflow+0x275/0x350 > > [] ? perf_event_task_disable+0xa0/0xa0 > > [] ? x86_perf_event_set_period+0xbf/0x150 > > [] perf_event_overflow+0x14/0x20 > > [] intel_pmu_handle_irq+0x206/0x410 > > [] ? arch_vtime_task_switch+0x63/0x130 > > [] perf_event_nmi_handler+0x2b/0x50 > > [] nmi_handle+0xd2/0x390 > > [] ? nmi_handle+0x5/0x390 > > [] ? lock_release+0xab/0x330 > > [] default_do_nmi+0x72/0x1c0 > > [] ? cpuacct_account_field+0xcf/0x200 > > [] do_nmi+0xb8/0x100 > > [] end_repeat_nmi+0x1e/0x2e > > [] ? cpuacct_account_field+0xcf/0x200 > > [] ? lock_release+0xab/0x330 > > [] ? lock_release+0xab/0x330 > > [] ? lock_release+0xab/0x330 > > <> [] cpuacct_account_field+0xe7/0x200 > > [] ? cpuacct_account_field+0x5/0x200 > > [] account_system_time+0x98/0x1a0 > > [] __vtime_account_system+0x2e/0x40 > > [] vtime_user_enter+0x59/0x90 > > [] ? context_tracking_user_enter+0xd3/0x1f0 > > [] context_tracking_user_enter+0xd3/0x1f0 > > [] syscall_trace_leave+0xa5/0x210 > > [] 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.