From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5002C433EF for ; Tue, 26 Oct 2021 09:26:42 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7ED256103C for ; Tue, 26 Oct 2021 09:26:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7ED256103C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date:Subject:Cc:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=olLsel1ZTUo8r8KBpFNPZ4S8USujR/Na9lrlxiVO6Xk=; b=B4WX6I5aQxgCuE gxxfqBSNw9v0XZm8Ldi+MelQXHuc/UpmmoI4B8JQKFBcV1sJTCJc84ZFxXYtMR1eC3ugq/pDi3F2b 7SDzVaGx0b2cl9brDVcqpACfgYGguUE3KjLAE8qa5CVjEpAQnrOS/zAWV6AdoqkngIwd1xF7UVg86 M7hXafUDx6p5xe7zNGAVUmFJzC/Qoth8yeyWOnwUQgznaqGPYSUhzJYjxjAArDrcgmAVgYqXEmeXt 8Ti3Vcz/tXenDCzd5UhLOf68Zx0LpqiZFcL0+4SiZWecbvcx2z1ITNUvD1zTv7B/Z7ItbT2WbmdkI y09zq/tQzrAUXRY1Whfg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfIht-001DeL-Ek; Tue, 26 Oct 2021 09:25:21 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfIhp-001Dcw-S6 for linux-arm-kernel@lists.infradead.org; Tue, 26 Oct 2021 09:25:19 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 04D351FB; Tue, 26 Oct 2021 02:25:12 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 066FE3F70D; Tue, 26 Oct 2021 02:25:08 -0700 (PDT) From: Mark Rutland To: linux-kernel@vger.kernel.org, maz@kernel.org Cc: aou@eecs.berkeley.edu, catalin.marinas@arm.com, deanbo422@gmail.com, green.hu@gmail.com, guoren@kernel.org, jonas@southpole.se, kernelfans@gmail.com, linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, mark.rutland@arm.com, nickhu@andestech.com, palmer@dabbelt.com, paul.walmsley@sifive.com, shorne@gmail.com, stefan.kristiansson@saunalahti.fi, tglx@linutronix.de, tsbogend@alpha.franken.de, vgupta@kernel.org, vladimir.murzin@arm.com, will@kernel.org, paulmck@kernel.org, peterz@infradead.org, torvalds@linux-foundation.org Subject: [PATCH v2 00/17] irq: remove handle_domain_{irq,nmi}() Date: Tue, 26 Oct 2021 10:24:47 +0100 Message-Id: <20211026092504.27071-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.11.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211026_022518_052627_E009ABD4 X-CRM114-Status: GOOD ( 22.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The handle_domain_{irq,nmi}() functions were oringally intended as a convenience, but recent rework to entry code across the kernel tree has demonstrated that they cause more pain than they're worth and prevent architectures from being able to write robust entry code. This series reworks the irq code to remove them, handling the necessary entry work consistently in entry code (be it architectural or generic). Marc, on the assumption you'll take this into the irqchip tree, I've pushed this out to my kernel.org repo, tagged as remove-handle-domain-irq-20211026, which should be commit: 0953fb263714e1c8 ("irq: remove handle_domain_{irq,nmi}() (2021-10-26 10:13:31 +0100)") Since v1 [1]: * Accumulate tags * Simplify bcm6345_l1_irq_handle() * Don't export generic_handle_domain_nmi() * Unexport handle_irq_desc() [1] https://lore.kernel.org/r/20211021180236.37428-1-mark.rutland@arm.com The gory details are in the thread starting at: https://lore.kernel.org/r/20211011104729.GB1421@C02TD0UTHF1T.local ... which can be summarized as: * At entry time, entry code needs to poke lockdep, RCU, and irqflag tracing in a specific order due to interdependencies, before most other C code can run. Part of this involves calling rcu_irq_enter(). Currently, arm64 is the only architecture which uses handle_domain_irq() and performs the nominally correct sequence (which is aligned with the generic entry code we aim to move to in future). * RCU relies on rcu_irq_enter() being called precisely once per IRQ exception, or rcu_is_cpu_rrupt_from_idle() may fail to identify wakeups from idle, and RCU may not trigger a reschedule when necessary, leading to RCU stalls. * The handle_domain_irq() helper, which is called from irqchip code between the entry code and interrupt handlers, calls rcu_irq_enter(), consequently causing problems for RCU on arm64. In the thread Linus decreed: I really think that if the rule is "we can't do accounting in handle_domain_irq(), because it's too late for arm64", then the fix really should be to just not do that. Move the irq_enter()/irq_exit() to the callers - quite possibly far up the call chain to the root of it all, and just say "architecture code needs to do this in the low-level code before calling handle_arch_irq". This series does so, making entry code responsible for the IRQ entry work, and removing the handle_domain_{irq,nmi}() functions entirely so we're not tempted to reintroduce similar problems in future. The rework fixes a couple of latent bugs for MIPS, fixes the problem originally diagnosed for arm64, and should make it easier for the other architectures using handle_domain_irq() to move to nominally correct entry sequencing (e.g. by moving to the generic entry code). I've added a couple of checks to generic_handle_irq() and generic_handle_domain_irq() to verify that architectures are correctly performing the required entry work (which fingers crossed, shouldn't fire). Other than the above, there should be no functional change as result of these changes (except that previously erroneous usage of RCU in irqchip code will have become correct by virtue of RCU starting to watch earlier). I've given the series some light build and boot testing so far. Thanks, Mark. Mark Rutland (17): irq: mips: avoid nested irq_enter() irq: mips: simplify bcm6345_l1_irq_handle() irq: mips: stop (ab)using handle_domain_irq() irq: mips: simplify do_domain_IRQ() irq: simplify handle_domain_{irq,nmi}() irq: unexport handle_irq_desc() irq: add generic_handle_arch_irq() irq: arc: avoid CONFIG_HANDLE_DOMAIN_IRQ irq: nds32: avoid CONFIG_HANDLE_DOMAIN_IRQ irq: add a (temporary) CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY irq: arm: perform irqentry in entry code irq: arm64: perform irqentry in entry code irq: csky: perform irqentry in entry code irq: openrisc: perform irqentry in entry code irq: riscv: perform irqentry in entry code irq: remove CONFIG_HANDLE_DOMAIN_IRQ_IRQENTRY irq: remove handle_domain_{irq,nmi}() Documentation/core-api/irq/irq-domain.rst | 3 -- arch/arc/Kconfig | 1 - arch/arc/kernel/irq.c | 10 +++- arch/arm/Kconfig | 1 - arch/arm/kernel/entry-armv.S | 5 +- arch/arm/kernel/irq.c | 14 +++--- arch/arm/mach-imx/avic.c | 2 +- arch/arm/mach-imx/tzic.c | 2 +- arch/arm/mach-omap1/irq.c | 2 +- arch/arm/mach-s3c/irq-s3c24xx.c | 2 +- arch/arm64/Kconfig | 1 - arch/arm64/kernel/entry-common.c | 52 ++++++++++++-------- arch/csky/Kconfig | 1 - arch/csky/kernel/entry.S | 2 +- arch/csky/kernel/irq.c | 5 -- arch/mips/Kconfig | 1 - arch/mips/cavium-octeon/octeon-irq.c | 5 +- arch/mips/kernel/irq.c | 6 +-- arch/nds32/Kconfig | 1 - arch/openrisc/Kconfig | 1 - arch/openrisc/kernel/entry.S | 4 +- arch/openrisc/kernel/irq.c | 5 -- arch/riscv/Kconfig | 1 - arch/riscv/kernel/entry.S | 3 +- arch/riscv/kernel/smp.c | 9 +--- drivers/irqchip/irq-apple-aic.c | 20 ++++---- drivers/irqchip/irq-armada-370-xp.c | 13 ++--- drivers/irqchip/irq-aspeed-vic.c | 2 +- drivers/irqchip/irq-ativic32.c | 22 ++++++++- drivers/irqchip/irq-atmel-aic.c | 2 +- drivers/irqchip/irq-atmel-aic5.c | 2 +- drivers/irqchip/irq-bcm2835.c | 2 +- drivers/irqchip/irq-bcm2836.c | 2 +- drivers/irqchip/irq-bcm6345-l1.c | 6 +-- drivers/irqchip/irq-clps711x.c | 8 +-- drivers/irqchip/irq-csky-apb-intc.c | 2 +- drivers/irqchip/irq-csky-mpintc.c | 4 +- drivers/irqchip/irq-davinci-aintc.c | 2 +- drivers/irqchip/irq-davinci-cp-intc.c | 2 +- drivers/irqchip/irq-digicolor.c | 2 +- drivers/irqchip/irq-dw-apb-ictl.c | 2 +- drivers/irqchip/irq-ftintc010.c | 2 +- drivers/irqchip/irq-gic-v3.c | 4 +- drivers/irqchip/irq-gic.c | 2 +- drivers/irqchip/irq-hip04.c | 2 +- drivers/irqchip/irq-ixp4xx.c | 4 +- drivers/irqchip/irq-lpc32xx.c | 2 +- drivers/irqchip/irq-mmp.c | 4 +- drivers/irqchip/irq-mxs.c | 2 +- drivers/irqchip/irq-nvic.c | 17 ++++++- drivers/irqchip/irq-omap-intc.c | 2 +- drivers/irqchip/irq-or1k-pic.c | 2 +- drivers/irqchip/irq-orion.c | 4 +- drivers/irqchip/irq-rda-intc.c | 2 +- drivers/irqchip/irq-riscv-intc.c | 2 +- drivers/irqchip/irq-sa11x0.c | 4 +- drivers/irqchip/irq-sun4i.c | 2 +- drivers/irqchip/irq-versatile-fpga.c | 2 +- drivers/irqchip/irq-vic.c | 2 +- drivers/irqchip/irq-vt8500.c | 2 +- drivers/irqchip/irq-wpcm450-aic.c | 2 +- drivers/irqchip/irq-zevio.c | 2 +- include/linux/irq.h | 1 + include/linux/irqdesc.h | 9 +--- kernel/irq/Kconfig | 3 -- kernel/irq/handle.c | 18 +++++++ kernel/irq/irqdesc.c | 81 +++++++------------------------ 67 files changed, 192 insertions(+), 219 deletions(-) -- 2.11.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel