linux-kernel - [tip:x86/urgent] x86, irq: Check move_in_progress before freeing the vector mapping

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

Date:	Wed, 6 Jan 2010 20:24:39 GMT
From:	tip-bot for Suresh Siddha <suresh.b.siddha@...el.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...hat.com,
	garyhade@...ibm.com, suresh.b.siddha@...el.com, tglx@...utronix.de,
	ebiederm@...ssion.com
Subject: [tip:x86/urgent] x86, irq: Check move_in_progress before freeing the vector mapping

Commit-ID:  7f41c2e1523f628cc248e34192162aec5728bed7
Gitweb:     http://git.kernel.org/tip/7f41c2e1523f628cc248e34192162aec5728bed7
Author:     Suresh Siddha <suresh.b.siddha@...el.com>
AuthorDate: Wed, 6 Jan 2010 10:56:31 -0800
Committer:  H. Peter Anvin <hpa@...or.com>
CommitDate: Wed, 6 Jan 2010 12:08:43 -0800

x86, irq: Check move_in_progress before freeing the vector mapping

With the recent irq migration fixes (post 2.6.32), Gary Hade has noticed
"No IRQ handler for vector" messages during the 2.6.33-rc1 kernel boot on IBM
AMD platforms and root caused the issue to this commit:

> commit 23359a88e7eca3c4f402562b102f23014db3c2aa
> Author: Suresh Siddha <suresh.b.siddha@...el.com>
> Date:   Mon Oct 26 14:24:33 2009 -0800
>
>    x86: Remove move_cleanup_count from irq_cfg

As part of this patch, we have removed the move_cleanup_count check
in smp_irq_move_cleanup_interrupt(). With this change, we can run into a
situation where an irq cleanup interrupt on a cpu can cleanup the vector
mappings associated with multiple irqs, of which one of the irq's migration
might be still in progress. As such when that irq hits the old cpu, we get
the "No IRQ handler" messages.

Fix this by checking for the irq_cfg's move_in_progress and if the move
is still in progress delay the vector cleanup to another irq cleanup
interrupt request (which will happen when the irq starts arriving at the
new cpu destination).

Reported-and-tested-by: Gary Hade <garyhade@...ibm.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>
LKML-Reference: <1262804191.2732.7.camel@...-t61.sc.intel.com>
Cc: Eric W. Biederman <ebiederm@...ssion.com>
Signed-off-by: H. Peter Anvin <hpa@...or.com>
---
 arch/x86/kernel/apic/io_apic.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index de00c46..53243ca 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2434,6 +2434,13 @@ asmlinkage void smp_irq_move_cleanup_interrupt(void)
 		cfg = irq_cfg(irq);
 		raw_spin_lock(&desc->lock);
 
+		/*
+		 * Check if the irq migration is in progress. If so, we
+		 * haven't received the cleanup request yet for this irq.
+		 */
+		if (cfg->move_in_progress)
+			goto unlock;
+
 		if (vector == cfg->vector && cpumask_test_cpu(me, cfg->domain))
 			goto unlock;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/