Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751367AbbLTUyL (ORCPT ); Sun, 20 Dec 2015 15:54:11 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:34728 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751057AbbLTUxJ (ORCPT ); Sun, 20 Dec 2015 15:53:09 -0500 From: Daniel Thompson To: Thomas Gleixner , Jason Cooper , Russell King , Marc Zyngier Cc: Daniel Thompson , Will Deacon , Catalin Marinas , Stephen Boyd , John Stultz , Steven Rostedt , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, patches@linaro.org, linaro-kernel@lists.linaro.org, Sumit Semwal , Dirk Behme , Daniel Drake , Dmitry Pervushin , Tim Sander , Petr Mladek Subject: [PATCH 4.4-rc5 v22 4/4] ARM: Allow IPI_CPU_BACKTRACE to exploit FIQ Date: Sun, 20 Dec 2015 20:52:37 +0000 Message-Id: <1450644757-18734-5-git-send-email-daniel.thompson@linaro.org> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1450644757-18734-1-git-send-email-daniel.thompson@linaro.org> References: <1450644757-18734-1-git-send-email-daniel.thompson@linaro.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3130 Lines: 92 The GIC (v1 & v2) driver allows its implementation of handle_arch_irq() to be called from the FIQ handler but currently the ARM code is not able to exploit this. Extend handle_fiq_as_nmi() to call handle_arch_irq(). This will affect all interrupt controllers, including ones that do not support FIQ. This is OK because a spurious FIQ is normally fatal. Handling a spurious FIQ like a normal interrupt does risk deadlock but does give us a chance of surviving long enough to get an error message out. We also extend the SMP code to indicate to irq drivers which IPIs they should seek to implement using FIQ. Signed-off-by: Daniel Thompson --- arch/arm/include/asm/smp.h | 9 +++++++++ arch/arm/kernel/smp.c | 6 ++++++ arch/arm/kernel/traps.c | 9 ++++++++- 3 files changed, 23 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h index 3d6dc8b460e4..daf869cff02e 100644 --- a/arch/arm/include/asm/smp.h +++ b/arch/arm/include/asm/smp.h @@ -18,6 +18,15 @@ # error " included in non-SMP build" #endif +/* + * Identify which IPIs are safe for the irqchip to handle using FIQ. + * + * This information is advisory. The interrupt controller may not be capable + * of routing these IPIs to FIQ and the kernel will continue to work if they + * are routed to IRQ as normal. + */ +#define SMP_IPI_FIQ_MASK 0x80 + #define raw_smp_processor_id() (current_thread_info()->cpu) struct seq_file; diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index fe517f1e88d8..853089e1aa8a 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -639,6 +639,11 @@ void handle_IPI(int ipinr, struct pt_regs *regs) break; case IPI_CPU_BACKTRACE: + if (in_nmi()) { + nmi_cpu_backtrace(regs); + break; + } + irq_enter(); nmi_cpu_backtrace(regs); irq_exit(); @@ -750,6 +755,7 @@ static void raise_nmi(cpumask_t *mask) if (cpumask_test_cpu(smp_processor_id(), mask) && irqs_disabled()) nmi_cpu_backtrace(NULL); + BUILD_BUG_ON(SMP_IPI_FIQ_MASK != BIT(IPI_CPU_BACKTRACE)); smp_cross_call(mask, IPI_CPU_BACKTRACE); } diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c index bc698383e822..a04426ee7684 100644 --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -479,7 +479,14 @@ asmlinkage void __exception_irq_entry handle_fiq_as_nmi(struct pt_regs *regs) nmi_enter(); - /* nop. FIQ handlers for special arch/arm features can be added here. */ + /* + * Either the interrupt controller supports FIQ, meaning it will + * do the right thing with this call, or we will end up treating a + * spurious FIQ (which is normally fatal) as though it were an IRQ + * which, although it risks deadlock, still gives us a sporting + * chance of surviving long enough to log errors. + */ + handle_arch_irq(regs); nmi_exit(); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/