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,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: [PATCH 4.4 14/21] x86/irq: Prevent force migration of irqs which are not in the vector domain
Date: Fri, 14 Oct 2016 13:40:52 +0200	[thread overview]
Message-ID: <20161014114025.359208308@linuxfoundation.org> (raw)
In-Reply-To: <20161014114024.667943585@linuxfoundation.org>

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <mika.westerberg@linux.intel.com>

commit db91aa793ff984ac048e199ea1c54202543952fe upstream.

When a CPU is about to be offlined we call fixup_irqs() that resets IRQ
affinities related to the CPU in question. The same thing is also done when
the system is suspended to S-states like S3 (mem).

For each IRQ we try to complete any on-going move regardless whether the
IRQ is actually part of x86_vector_domain. For each IRQ descriptor we fetch
its chip_data, assume it is of type struct apic_chip_data and manipulate it
by clearing old_domain mask etc. For irq_chips that are not part of the
x86_vector_domain, like those created by various GPIO drivers, will find
their chip_data being changed unexpectly.

Below is an example where GPIO chip owned by pinctrl-sunrisepoint.c gets
corrupted after resume:

  # cat /sys/kernel/debug/gpio
  gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00:
   gpio-511 (                    |sysfs               ) in  hi

  # rtcwake -s10 -mmem
  <10 seconds passes>

  # cat /sys/kernel/debug/gpio
  gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00:
   gpio-511 (                    |sysfs               ) in  ?

Note '?' in the output. It means the struct gpio_chip ->get function is
NULL whereas before suspend it was there.

Fix this by first checking that the IRQ belongs to x86_vector_domain before
we try to use the chip_data as struct apic_chip_data.

Reported-and-tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: http://lkml.kernel.org/r/20161003101708.34795-1-mika.westerberg@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kernel/apic/vector.c |   23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -659,11 +659,28 @@ void irq_complete_move(struct irq_cfg *c
  */
 void irq_force_complete_move(struct irq_desc *desc)
 {
-	struct irq_data *irqdata = irq_desc_get_irq_data(desc);
-	struct apic_chip_data *data = apic_chip_data(irqdata);
-	struct irq_cfg *cfg = data ? &data->cfg : NULL;
+	struct irq_data *irqdata;
+	struct apic_chip_data *data;
+	struct irq_cfg *cfg;
 	unsigned int cpu;
 
+	/*
+	 * The function is called for all descriptors regardless of which
+	 * irqdomain they belong to. For example if an IRQ is provided by
+	 * an irq_chip as part of a GPIO driver, the chip data for that
+	 * descriptor is specific to the irq_chip in question.
+	 *
+	 * Check first that the chip_data is what we expect
+	 * (apic_chip_data) before touching it any further.
+	 */
+	irqdata = irq_domain_get_irq_data(x86_vector_domain,
+					  irq_desc_get_irq(desc));
+	if (!irqdata)
+		return;
+
+	data = apic_chip_data(irqdata);
+	cfg = data ? &data->cfg : NULL;
+
 	if (!cfg)
 		return;
 

  parent reply	other threads:[~2016-10-14 11:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20161014114058uscas1p2f11cd323e19fe39c72c2e1b1246b89ef@uscas1p2.samsung.com>
2016-10-14 11:40 ` [PATCH 4.4 00/21] 4.4.25-stable review Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 01/21] time: Add cycles to nanoseconds translation Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 02/21] timekeeping: Fix __ktime_get_fast_ns() regression Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 03/21] ALSA: ali5451: Fix out-of-bound position reporting Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 04/21] ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 05/21] ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 06/21] mfd: rtsx_usb: Avoid setting ucr->current_sg.status Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 07/21] mfd: atmel-hlcdc: Do not sleep in atomic context Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 08/21] mfd: 88pm80x: Double shifting bug in suspend/resume Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 10/21] KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 11/21] KVM: MIPS: Drop other CPU ASIDs on guest MMU changes Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 12/21] KVM: PPC: BookE: Fix a sanity check Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 13/21] x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation Greg Kroah-Hartman
2016-10-14 11:40     ` Greg Kroah-Hartman
2016-10-14 11:40     ` Greg Kroah-Hartman
2016-10-14 11:40   ` Greg Kroah-Hartman [this message]
2016-10-14 11:40   ` [PATCH 4.4 15/21] x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 16/21] ARM: dts: mvebu: armada-390: add missing compatibility string and bracket Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 18/21] ARM: cpuidle: Fix error return code Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 19/21] ima: use file_dentry() Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 20/21] tpm: fix a race condition in tpm2_unseal_trusted() Greg Kroah-Hartman
2016-10-14 11:40   ` [PATCH 4.4 21/21] tpm_crb: fix crb_req_canceled behavior Greg Kroah-Hartman
2016-10-14 18:46   ` [PATCH 4.4 00/21] 4.4.25-stable review Shuah Khan
2016-10-14 19:15   ` Guenter Roeck

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=20161014114025.359208308@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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.