linux-kernel - [tip: irq/core] genirq/msi: Shutdown managed interrupts with unsatifiable affinities

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <164961798087.4207.9105739459698939975.tip-bot2@tip-bot2>
Date:   Sun, 10 Apr 2022 19:13:00 -0000
From:   "tip-bot2 for Marc Zyngier" <tip-bot2@...utronix.de>
To:     linux-tip-commits@...r.kernel.org
Cc:     John Garry <john.garry@...wei.com>,
        David Decotigny <ddecotig@...gle.com>,
        Marc Zyngier <maz@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: [tip: irq/core] genirq/msi: Shutdown managed interrupts with
 unsatifiable affinities

The following commit has been merged into the irq/core branch of tip:

Commit-ID:     d802057c7c553ad426520a053da9f9fe08e2c35a
Gitweb:        https://git.kernel.org/tip/d802057c7c553ad426520a053da9f9fe08e2c35a
Author:        Marc Zyngier <maz@...nel.org>
AuthorDate:    Tue, 05 Apr 2022 19:50:38 +01:00
Committer:     Thomas Gleixner <tglx@...utronix.de>
CommitterDate: Sun, 10 Apr 2022 21:06:30 +02:00

genirq/msi: Shutdown managed interrupts with unsatifiable affinities

When booting with maxcpus=<small number>, interrupt controllers
such as the GICv3 ITS may not be able to satisfy the affinity of
some managed interrupts, as some of the HW resources are simply
not available.

The same thing happens when loading a driver using managed interrupts
while CPUs are offline.

In order to deal with this, do not try to activate such interrupt
if there is no online CPU capable of handling it. Instead, place
it in shutdown state. Once a capable CPU shows up, it will be
activated.

Reported-by: John Garry <john.garry@...wei.com>
Reported-by: David Decotigny <ddecotig@...gle.com>
Signed-off-by: Marc Zyngier <maz@...nel.org>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Tested-by: John Garry <john.garry@...wei.com>
Link: https://lore.kernel.org/r/20220405185040.206297-2-maz@kernel.org

---
 kernel/irq/msi.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 2bdfce5..a9ee535 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -818,6 +818,21 @@ static int msi_init_virq(struct irq_domain *domain, int virq, unsigned int vflag
 		irqd_clr_can_reserve(irqd);
 		if (vflags & VIRQ_NOMASK_QUIRK)
 			irqd_set_msi_nomask_quirk(irqd);
+
+		/*
+		 * If the interrupt is managed but no CPU is available to
+		 * service it, shut it down until better times. Note that
+		 * we only do this on the !RESERVE path as x86 (the only
+		 * architecture using this flag) deals with this in a
+		 * different way by using a catch-all vector.
+		 */
+		if ((vflags & VIRQ_ACTIVATE) &&
+		    irqd_affinity_is_managed(irqd) &&
+		    !cpumask_intersects(irq_data_get_affinity_mask(irqd),
+					cpu_online_mask)) {
+			    irqd_set_managed_shutdown(irqd);
+			    return 0;
+		    }
 	}
 
 	if (!(vflags & VIRQ_ACTIVATE))