All of lore.kernel.org
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: tglx@linutronix.de, gregkh@linuxfoundation.org,
	jiang.liu@linux.intel.com, mika.westerberg@linux.intel.com
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "x86/ioapic: Force affinity setting in setup_ioapic_dest()" has been added to the 4.2-stable tree
Date: Tue, 13 Oct 2015 14:50:11 -0700	[thread overview]
Message-ID: <14447730117056@kroah.com> (raw)


This is a note to let you know that I've just added the patch titled

    x86/ioapic: Force affinity setting in setup_ioapic_dest()

to the 4.2-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     x86-ioapic-force-affinity-setting-in-setup_ioapic_dest.patch
and it can be found in the queue-4.2 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From 4857c91f0d195f05908fff296ba1ec5fca87066c Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx@linutronix.de>
Date: Mon, 14 Sep 2015 12:00:55 +0200
Subject: x86/ioapic: Force affinity setting in setup_ioapic_dest()

From: Thomas Gleixner <tglx@linutronix.de>

commit 4857c91f0d195f05908fff296ba1ec5fca87066c upstream.

The recent ioapic cleanups changed the affinity setting in
setup_ioapic_dest() from a direct write to the hardware to the delayed
affinity setup via irq_set_affinity().

That results in a warning from chained_irq_exit():
WARNING: CPU: 0 PID: 5 at kernel/irq/migration.c:32 irq_move_masked_irq
[<ffffffff810a0a88>] irq_move_masked_irq+0xb8/0xc0
[<ffffffff8103c161>] ioapic_ack_level+0x111/0x130
[<ffffffff812bbfe8>] intel_gpio_irq_handler+0x148/0x1c0

The reason is that irq_set_affinity() does not write directly to the
hardware. It marks the affinity setting as pending and executes it
from the next interrupt. The chained handler infrastructure does not
take the irq descriptor lock for performance reasons because such a
chained interrupt is not visible to any interfaces. So the delayed
affinity setting triggers the warning in irq_move_masked_irq().

Restore the old behaviour by calling the set_affinity function of the
ioapic chip in setup_ioapic_dest(). This is safe as none of the
interrupts can be on the fly at this point.

Fixes: aa5cb97f14a2 'x86/irq: Remove x86_io_apic_ops.set_affinity and related interfaces'
Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: jarkko.nikula@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kernel/apic/io_apic.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2522,6 +2522,7 @@ void __init setup_ioapic_dest(void)
 	int pin, ioapic, irq, irq_entry;
 	const struct cpumask *mask;
 	struct irq_data *idata;
+	struct irq_chip *chip;
 
 	if (skip_ioapic_setup == 1)
 		return;
@@ -2545,9 +2546,9 @@ void __init setup_ioapic_dest(void)
 		else
 			mask = apic->target_cpus();
 
-		irq_set_affinity(irq, mask);
+		chip = irq_data_get_irq_chip(idata);
+		chip->irq_set_affinity(idata, mask, false);
 	}
-
 }
 #endif
 


Patches currently in stable-queue which might be from tglx@linutronix.de are

queue-4.2/time-fix-timekeeping_freqadjust-s-incorrect-use-of-abs-instead-of-abs64.patch
queue-4.2/x86-platform-fix-geode-lx-timekeeping-in-the-generic-x86-build.patch
queue-4.2/x86-pci-intel_mid_pci-work-around-for-irq0-assignment.patch
queue-4.2/x86-ioapic-force-affinity-setting-in-setup_ioapic_dest.patch
queue-4.2/x86-alternatives-make-optimize_nops-interrupt-safe-and-synced.patch
queue-4.2/x86-apic-serialize-lvtt-and-tsc_deadline-writes.patch
queue-4.2/perf-x86-intel-fix-constraint-access.patch
queue-4.2/locking-qspinlock-x86-only-emit-the-test-and-set-fallback-when-building-guest-support.patch
queue-4.2/locking-qspinlock-x86-fix-performance-regression-under-unaccelerated-vms.patch

                 reply	other threads:[~2015-10-13 21:50 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=14447730117056@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=jiang.liu@linux.intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=stable-commits@vger.kernel.org \
    --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.