linux-kernel - [PATCH] genirq: Deduplicate WARN_ON_ONCE() in generic_handle_domain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <c3caf60bfa78e5fdbdf483096b7174da65d1813a.1652168866.git.lukas@wunner.de>
Date:   Tue, 10 May 2022 09:56:05 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        linux-gpio@...r.kernel.org,
        Octavian Purdila <octavian.purdila@....com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: [PATCH] genirq: Deduplicate WARN_ON_ONCE() in
 generic_handle_domain_irq()

Since commit 0953fb263714 ("irq: remove handle_domain_{irq,nmi}()"),
generic_handle_domain_irq() warns if called outside hardirq context,
even though the function calls down to handle_irq_desc(), which warns
about the same.

Moreover the newly added warning is false positive if the interrupt
originates from any other irqchip than x86 APIC or arm GIC/GICv3.
Those are the only ones for which handle_enforce_irqctx() returns true.
Per commit c16816acd086 ("genirq: Add protection against unsafe usage of
generic_handle_irq()"):

 "In general calling generic_handle_irq() with interrupts disabled from
  non interrupt context is harmless.  [But for] interrupt controllers
  like the x86 trainwrecks this is outright dangerous as it might
  corrupt state if an interrupt affinity change is pending."

An example for irqchips where the warning is false positive are
USB-attached GPIO controllers such as drivers/gpio/gpio-dln2.c:
USB gadgets are incapable of directly signaling an interrupt because
they cannot initiate a bus transaction by themselves.  All communication
on the bus is initiated by the host controller, which polls a gadget's
Interrupt Endpoint in regular intervals.  If an interrupt is pending,
that information is passed up the stack in softirq context, from which
a hardirq is synthesized via generic_handle_domain_irq().

Deduplicate the warning to eliminate false positives and speed up IRQ
handling.

Fixes: 0953fb263714 ("irq: remove handle_domain_{irq,nmi}()")
Signed-off-by: Lukas Wunner <lukas@...ner.de>
Cc: stable@...r.kernel.org # v5.16+
Cc: Mark Rutland <mark.rutland@....com>
---
 kernel/irq/irqdesc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 939d21c..da3e495 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -699,7 +699,6 @@ int generic_handle_irq_safe(unsigned int irq)
  */
 int generic_handle_domain_irq(struct irq_domain *domain, unsigned int hwirq)
 {
-	WARN_ON_ONCE(!in_hardirq());
 	return handle_irq_desc(irq_resolve_mapping(domain, hwirq));
 }
 EXPORT_SYMBOL_GPL(generic_handle_domain_irq);
-- 
2.35.2