All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Vitaly Kuznetsov <vkuznets@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: [PATCH 4.4 11/14] x86/ioapic: Ignore IRQ2 again
Date: Mon, 22 Mar 2021 13:29:05 +0100	[thread overview]
Message-ID: <20210322121919.547111845@linuxfoundation.org> (raw)
In-Reply-To: <20210322121919.202392464@linuxfoundation.org>

From: Thomas Gleixner <tglx@linutronix.de>

commit a501b048a95b79e1e34f03cac3c87ff1e9f229ad upstream.

Vitaly ran into an issue with hotplugging CPU0 on an Amazon instance where
the matrix allocator claimed to be out of vectors. He analyzed it down to
the point that IRQ2, the PIC cascade interrupt, which is supposed to be not
ever routed to the IO/APIC ended up having an interrupt vector assigned
which got moved during unplug of CPU0.

The underlying issue is that IRQ2 for various reasons (see commit
af174783b925 ("x86: I/O APIC: Never configure IRQ2" for details) is treated
as a reserved system vector by the vector core code and is not accounted as
a regular vector. The Amazon BIOS has an routing entry of pin2 to IRQ2
which causes the IO/APIC setup to claim that interrupt which is granted by
the vector domain because there is no sanity check. As a consequence the
allocation counter of CPU0 underflows which causes a subsequent unplug to
fail with:

  [ ... ] CPU 0 has 4294967295 vectors, 589 available. Cannot disable CPU

There is another sanity check missing in the matrix allocator, but the
underlying root cause is that the IO/APIC code lost the IRQ2 ignore logic
during the conversion to irqdomains.

For almost 6 years nobody complained about this wreckage, which might
indicate that this requirement could be lifted, but for any system which
actually has a PIC IRQ2 is unusable by design so any routing entry has no
effect and the interrupt cannot be connected to a device anyway.

Due to that and due to history biased paranoia reasons restore the IRQ2
ignore logic and treat it as non existent despite a routing entry claiming
otherwise.

Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces")
Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210318192819.636943062@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/kernel/apic/io_apic.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1040,6 +1040,16 @@ static int mp_map_pin_to_irq(u32 gsi, in
 	if (idx >= 0 && test_bit(mp_irqs[idx].srcbus, mp_bus_not_pci)) {
 		irq = mp_irqs[idx].srcbusirq;
 		legacy = mp_is_legacy_irq(irq);
+		/*
+		 * IRQ2 is unusable for historical reasons on systems which
+		 * have a legacy PIC. See the comment vs. IRQ2 further down.
+		 *
+		 * If this gets removed at some point then the related code
+		 * in lapic_assign_system_vectors() needs to be adjusted as
+		 * well.
+		 */
+		if (legacy && irq == PIC_CASCADE_IR)
+			return -EINVAL;
 	}
 
 	mutex_lock(&ioapic_mutex);



  parent reply	other threads:[~2021-03-22 13:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22 12:28 [PATCH 4.4 00/14] 4.4.263-rc1 review Greg Kroah-Hartman
2021-03-22 12:28 ` [PATCH 4.4 01/14] ext4: handle error of ext4_setup_system_zone() on remount Greg Kroah-Hartman
2021-03-22 12:28 ` [PATCH 4.4 02/14] ext4: dont allow overlapping system zones Greg Kroah-Hartman
2021-03-22 12:28 ` [PATCH 4.4 03/14] ext4: check journal inode extents more carefully Greg Kroah-Hartman
2021-03-22 12:28 ` [PATCH 4.4 04/14] platform/chrome: cros_ec_dev - Fix security issue Greg Kroah-Hartman
2021-03-22 12:28 ` [PATCH 4.4 05/14] btrfs: fix race when cloning extent buffer during rewind of an old root Greg Kroah-Hartman
2021-03-22 12:29 ` [PATCH 4.4 06/14] NFSD: Repair misuse of sv_lock in 5.10.16-rt30 Greg Kroah-Hartman
2021-03-22 12:29 ` [PATCH 4.4 07/14] scsi: lpfc: Fix some error codes in debugfs Greg Kroah-Hartman
2021-03-22 12:29 ` [PATCH 4.4 08/14] USB: replace hardcode maximum usb string length by definition Greg Kroah-Hartman
2021-03-22 12:29 ` [PATCH 4.4 09/14] usb: gadget: configfs: Fix KASAN use-after-free Greg Kroah-Hartman
2021-03-22 12:29 ` [PATCH 4.4 10/14] PCI: rpadlpar: Fix potential drc_name corruption in store functions Greg Kroah-Hartman
2021-03-22 12:29 ` Greg Kroah-Hartman [this message]
2021-03-22 12:29 ` [PATCH 4.4 12/14] ext4: find old entry again if failed to rename whiteout Greg Kroah-Hartman
2021-03-22 12:29 ` [PATCH 4.4 13/14] ext4: fix potential error in ext4_do_update_inode Greg Kroah-Hartman
2021-03-22 12:29 ` [PATCH 4.4 14/14] genirq: Disable interrupts for force threaded handlers Greg Kroah-Hartman
2021-03-22 14:35 ` [PATCH 4.4 00/14] 4.4.263-rc1 review Jon Hunter
2021-03-22 20:14 ` Pavel Machek
2021-03-22 21:55 ` Guenter Roeck
2021-03-23 13:30 ` Naresh Kamboju

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210322121919.547111845@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.