From: Thomas Gleixner <tglx@linutronix.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Peter Anvin <hpa@zytor.com>, xiao jin <jin.xiao@intel.com>,
Joerg Roedel <jroedel@suse.de>, Borislav Petkov <bp@suse.de>,
Yanmin Zhang <yanmin_zhang@linux.intel.com>
Subject: [patch 2/4] x86: Plug irq vector hotplug race
Date: Sun, 05 Jul 2015 17:12:32 -0000 [thread overview]
Message-ID: <20150705171102.141898931@linutronix.de> (raw)
In-Reply-To: 20150705170530.849428850@linutronix.de
[-- Attachment #1: x86-plug-irq-vector-race.patch --]
[-- Type: text/plain, Size: 4634 bytes --]
Jin debugged a nasty cpu hotplug race which results in leaking a irq
vector on the newly hotplugged cpu.
cpu N cpu M
native_cpu_up device_shutdown
do_boot_cpu free_msi_irqs
start_secondary arch_teardown_msi_irqs
smp_callin default_teardown_msi_irqs
setup_vector_irq arch_teardown_msi_irq
__setup_vector_irq native_teardown_msi_irq
lock(vector_lock) destroy_irq
install vectors
unlock(vector_lock)
lock(vector_lock)
---> __clear_irq_vector
unlock(vector_lock)
lock(vector_lock)
set_cpu_online
unlock(vector_lock)
This leaves the irq vector(s) which are torn down on CPU M stale in
the vector array of CPU N, because CPU M does not see CPU N online
yet. There is a similar issue with concurrent newly setup interrupts.
The alloc/free protection of irq descriptors does not prevent the
above race, because it merily prevents interrupt descriptors from
going away or changing concurrently.
Prevent this by moving the call to setup_vector_irq() into the
vector_lock held region which protects set_cpu_online():
cpu N cpu M
native_cpu_up device_shutdown
do_boot_cpu free_msi_irqs
start_secondary arch_teardown_msi_irqs
smp_callin default_teardown_msi_irqs
lock(vector_lock) arch_teardown_msi_irq
setup_vector_irq()
__setup_vector_irq native_teardown_msi_irq
install vectors destroy_irq
set_cpu_online
unlock(vector_lock)
lock(vector_lock)
__clear_irq_vector
unlock(vector_lock)
So cpu M either sees the cpu N online before clearing the vector or
cpu N installs the vectors after cpu M has cleared it.
Reported-by: xiao jin <jin.xiao@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/x86/kernel/apic/vector.c | 10 ++--------
arch/x86/kernel/smpboot.c | 13 +++++--------
2 files changed, 7 insertions(+), 16 deletions(-)
Index: tip/arch/x86/kernel/apic/vector.c
===================================================================
--- tip.orig/arch/x86/kernel/apic/vector.c
+++ tip/arch/x86/kernel/apic/vector.c
@@ -409,12 +409,6 @@ static void __setup_vector_irq(int cpu)
int irq, vector;
struct apic_chip_data *data;
- /*
- * vector_lock will make sure that we don't run into irq vector
- * assignments that might be happening on another cpu in parallel,
- * while we setup our initial vector to irq mappings.
- */
- raw_spin_lock(&vector_lock);
/* Mark the inuse vectors */
for_each_active_irq(irq) {
data = apic_chip_data(irq_get_irq_data(irq));
@@ -436,16 +430,16 @@ static void __setup_vector_irq(int cpu)
if (!cpumask_test_cpu(cpu, data->domain))
per_cpu(vector_irq, cpu)[vector] = VECTOR_UNDEFINED;
}
- raw_spin_unlock(&vector_lock);
}
/*
- * Setup the vector to irq mappings.
+ * Setup the vector to irq mappings. Must be called with vector_lock held.
*/
void setup_vector_irq(int cpu)
{
int irq;
+ lockdep_assert_held(&vector_lock);
/*
* On most of the platforms, legacy PIC delivers the interrupts on the
* boot cpu. But there are certain platforms where PIC interrupts are
Index: tip/arch/x86/kernel/smpboot.c
===================================================================
--- tip.orig/arch/x86/kernel/smpboot.c
+++ tip/arch/x86/kernel/smpboot.c
@@ -171,11 +171,6 @@ static void smp_callin(void)
apic_ap_setup();
/*
- * Need to setup vector mappings before we enable interrupts.
- */
- setup_vector_irq(smp_processor_id());
-
- /*
* Save our processor parameters. Note: this information
* is needed for clock calibration.
*/
@@ -246,11 +241,13 @@ static void notrace start_secondary(void
#endif
/*
- * We need to hold vector_lock so there the set of online cpus
- * does not change while we are assigning vectors to cpus. Holding
- * this lock ensures we don't half assign or remove an irq from a cpu.
+ * Lock vector_lock and initialize the vectors on this cpu
+ * before setting the cpu online. We must set it online with
+ * vector_lock held to prevent a concurrent setup/teardown
+ * from seeing a half valid vector space.
*/
lock_vector_lock();
+ setup_vector_irq(smp_processor_id());
set_cpu_online(smp_processor_id(), true);
unlock_vector_lock();
cpu_set_state_online(smp_processor_id());
next prev parent reply other threads:[~2015-07-05 17:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-05 17:12 [patch 0/4] x86/irq: Plug a couple of cpu hotplug races Thomas Gleixner
2015-07-05 17:12 ` [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down Thomas Gleixner
2015-07-07 9:48 ` [tip:irq/urgent] hotplug: Prevent alloc/ free " tip-bot for Thomas Gleixner
2015-07-07 20:06 ` tip-bot for Thomas Gleixner
2015-07-08 9:37 ` tip-bot for Thomas Gleixner
2015-07-14 14:39 ` [patch 1/4] hotplug: Prevent alloc/free " Boris Ostrovsky
2015-07-14 15:44 ` Thomas Gleixner
2015-07-14 16:03 ` Boris Ostrovsky
2015-07-14 17:32 ` Thomas Gleixner
2015-07-14 20:04 ` [Xen-devel] " Boris Ostrovsky
2015-07-14 20:15 ` Thomas Gleixner
2015-07-14 21:07 ` Boris Ostrovsky
2016-03-12 9:19 ` Thomas Gleixner
2016-03-14 13:12 ` Boris Ostrovsky
2015-07-05 17:12 ` Thomas Gleixner [this message]
2015-07-07 9:57 ` [tip:x86/urgent] x86/irq: Plug irq vector hotplug race tip-bot for Thomas Gleixner
2015-07-05 17:12 ` [patch 3/4] x86/irq: Use proper locking in check_irq_vectors_for_cpu_disable() Thomas Gleixner
2015-07-07 9:57 ` [tip:x86/urgent] " tip-bot for Thomas Gleixner
2015-07-05 17:12 ` [patch 4/4] x86/irq: Retrieve irq data after locking irq_desc Thomas Gleixner
2015-07-07 9:58 ` [tip:x86/urgent] " tip-bot for Thomas Gleixner
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=20150705171102.141898931@linutronix.de \
--to=tglx@linutronix.de \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=jin.xiao@intel.com \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=yanmin_zhang@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox