From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933248AbcCOBVE (ORCPT ); Mon, 14 Mar 2016 21:21:04 -0400 Received: from arcturus.aphlor.org ([188.246.204.175]:44336 "EHLO arcturus.aphlor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932254AbcCOBVA (ORCPT ); Mon, 14 Mar 2016 21:21:00 -0400 Date: Mon, 14 Mar 2016 21:20:54 -0400 From: Dave Jones To: x86@kernel.org Cc: Linux Kernel , Andi Kleen Subject: Fix suspicious RCU usage in msr tracing. Message-ID: <20160315012054.GA17765@codemonkey.org.uk> Mail-Followup-To: Dave Jones , x86@kernel.org, Linux Kernel , Andi Kleen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "arcturus.aphlor.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Since 4.4, I've been able to trigger this occasionally: =============================== [ INFO: suspicious RCU usage. ] 4.5.0-rc7-think+ #3 Not tainted ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage! [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since 4.4, I've been able to trigger this occasionally: =============================== [ INFO: suspicious RCU usage. ] 4.5.0-rc7-think+ #3 Not tainted ------------------------------- ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 1 RCU used illegally from extended quiescent state! no locks held by swapper/3/0. stack backtrace: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3 ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6 ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60 Call Trace: [] dump_stack+0x67/0x9d [] lockdep_rcu_suspicious+0xe6/0x100 [] do_trace_write_msr+0x127/0x1a0 [] native_apic_msr_eoi_write+0x23/0x30 [] smp_trace_call_function_interrupt+0x38/0x360 [] trace_call_function_interrupt+0x90/0xa0 [] ? cpuidle_enter_state+0x1b4/0x520 [] cpuidle_enter+0x17/0x20 [] cpu_startup_entry+0x4e4/0x610 [] ? default_idle_call+0x60/0x60 [] ? clockevents_config_and_register+0x64/0x70 [] start_secondary+0x283/0x390 [] ? set_cpu_sibling_map+0x970/0x970 Back in January, Andi suggested swapping the order in which we ack the APIC irq, so it too is protected by rcu. There was no follow-up, and it seems to work for me. Cc: Andi Kleen Signed-off-by: Dave Jones diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h index c80f6b6f3da2..e8c4fba52d3d 100644 --- a/arch/x86/include/asm/apic.h +++ b/arch/x86/include/asm/apic.h @@ -644,8 +644,8 @@ static inline void entering_irq(void) static inline void entering_ack_irq(void) { - ack_APIC_irq(); entering_irq(); + ack_APIC_irq(); } static inline void ipi_entering_ack_irq(void)