public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Suresh Siddha <suresh.b.siddha@intel.com>
To: mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com,
	dwmw2@infradead.org, yinghai@kernel.org, steiner@sgi.com
Cc: linux-kernel@vger.kernel.org,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: [patch 12/13] x86: fix broken irq migration logic while cleaning up multiple vectors
Date: Mon, 16 Mar 2009 17:05:04 -0700	[thread overview]
Message-ID: <20090317001321.398981000@linux-os.sc.intel.com> (raw)
In-Reply-To: 20090317000452.805772000@linux-os.sc.intel.com

[-- Attachment #1: fix_spurious_interrupt.patch --]
[-- Type: text/plain, Size: 2633 bytes --]

During irq migration, we send a low priority interrupt to the previous
irq destination. This happens in non interrupt-remapping case after interrupt
starts arriving at new destination and in interrupt-remapping case after
modifying and flushing the interrupt-remapping table entry caches.

This low priority irq cleanup handler can cleanup multiple vectors, as
multiple irq's can be migrated at almost the same time. While
there will be multiple invocations of irq cleanup handler (one cleanup
IPI for each irq migration), first invocation of the cleanup handler
can potentially cleanup more than one vector (as the first invocation can
see the requests for more than vector cleanup). When we cleanup multiple
vectors during the first invocation of the smp_irq_move_cleanup_interrupt(),
other vectors that are to be cleanedup can still be pending in the local
cpu's IRR (as smp_irq_move_cleanup_interrupt() runs with interrupts disabled).

When we are ready to unhook a vector corresponding to an irq, check if that
vector is registered in the local cpu's IRR. If so skip that cleanup and
do a self IPI with the cleanup vector, so that we give a chance to
service the pending vector interrupt and then cleanup that vector
allocation once we execute the lowest priority handler.

This fixes spurious interrupts seen when migrating multiple vectors
at the same time.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
---

Index: tip/arch/x86/kernel/apic/io_apic.c
===================================================================
--- tip.orig/arch/x86/kernel/apic/io_apic.c
+++ tip/arch/x86/kernel/apic/io_apic.c
@@ -2414,6 +2414,7 @@ asmlinkage void smp_irq_move_cleanup_int
 	me = smp_processor_id();
 	for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; vector++) {
 		unsigned int irq;
+		unsigned int irr;
 		struct irq_desc *desc;
 		struct irq_cfg *cfg;
 		irq = __get_cpu_var(vector_irq)[vector];
@@ -2433,6 +2434,18 @@ asmlinkage void smp_irq_move_cleanup_int
 		if (vector == cfg->vector && cpumask_test_cpu(me, cfg->domain))
 			goto unlock;
 
+		irr = apic_read(APIC_IRR + (vector / 32 * 0x10));
+		/*
+		 * Check if the vector that needs to be cleanedup is
+		 * registered at the cpu's IRR. If so, then this is not
+		 * the best time to clean it up. Lets clean it up in the
+		 * next attempt by sending another IRQ_MOVE_CLEANUP_VECTOR
+		 * to myself.
+		 */
+		if (irr  & (1 << (vector % 32))) {
+			apic->send_IPI_self(IRQ_MOVE_CLEANUP_VECTOR);
+			goto unlock;
+		}
 		__get_cpu_var(vector_irq)[vector] = -1;
 		cfg->move_cleanup_count--;
 unlock:

-- 


  parent reply	other threads:[~2009-03-17  0:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17  0:04 [patch 00/13] x2apic and interrupt-remapping related fixes Suresh Siddha
2009-03-17  0:04 ` [patch 01/13] intr-remapping: fix "hard-safe -> hard-unsafe lock order detected" with irq_2_ir_lock Suresh Siddha
2009-03-17  0:04 ` [patch 02/13] dmar: move page fault handling code to dmar.c Suresh Siddha
2009-03-17  0:04 ` [patch 03/13] enable fault handling for intr-remapping Suresh Siddha
2009-03-17  0:04 ` [patch 04/13] dmar: routines for disabling queued invalidation and intr remapping Suresh Siddha
2009-03-17  0:04 ` [patch 05/13] dmar: start with sane state while enabling dma and interrupt-remapping Suresh Siddha
2009-03-17  0:04 ` [patch 06/13] intr-remapping: fix free_irte() to clear all the IRTE entries Suresh Siddha
2009-03-17  0:04 ` [patch 07/13] x2apic: use virtual wire A mode in disable_IO_APIC() with interrupt-remapping Suresh Siddha
2009-03-17  0:05 ` [patch 08/13] x86: fix clear_local_APIC() in the presence of x2apic Suresh Siddha
2009-03-17  0:05 ` [patch 09/13] x86: cleanup the IO-APIC level migration with interrupt-remapping Suresh Siddha
2009-03-17  0:05 ` [patch 10/13] cleanup ifdef CONFIG_INTR_REMAP in io_apic code Suresh Siddha
2009-03-17  0:05 ` [patch 11/13] ioapic: Fix non atomic allocation with interrupts disabled Suresh Siddha
2009-04-09 15:08   ` Jaswinder Singh Rajput
2009-03-17  0:05 ` Suresh Siddha [this message]
2009-03-17  0:05 ` [patch 13/13] dmar: use atomic allocations for QI and Intr-remapping init Suresh Siddha

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=20090317001321.398981000@linux-os.sc.intel.com \
    --to=suresh.b.siddha@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /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