Flush MSI-X table writes (rev 3)

This patch fixes a kernel bug which is triggered when using the irqbalance daemon with MSI-X hardware.

Because both MSI-X interrupt messages and MSI-X table writes are posted, it's possible for them to cross while in-flight. This results in interrupts being received long after the kernel thinks they're disabled, and in interrupts being sent to stale vectors after rebalancing.

This patch performs a read flush after writes to the MSI-X table for mask and unmask operations. Since the SMP affinity is set while the interrupt is masked, and since it's unmasked immediately after, no additional flushes are required in the various affinity setting routines.

This patch has been validated with (unreleased) network hardware which uses MSI-X.

Revised with input from Eric Biederman.

diff -urpN -X dontdiff linux-2.6.20.4-clean/drivers/pci/msi.c linux-2.6.20.4/drivers/pci/msi.c
@@ -40,6 +40,29 @@ static int msi_cache_init(void)
 	return 0;
 }
 
+static void msix_flush_writes(unsigned int irq)
+{
+	struct msi_desc *entry;
+
+	entry = msi_desc[irq];
+	BUG_ON(!entry || !entry->dev);
+	switch (entry->msi_attrib.type) {
+	case PCI_CAP_ID_MSI:
+		/* nothing to do */
+		break;
+	case PCI_CAP_ID_MSIX:
+	{
+		int offset = entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
+			PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET;
+		readl(entry->mask_base + offset);
+		break;
+	}
+	default:
+		BUG();
+		break;
+	}
+}
+
 static void msi_set_mask_bit(unsigned int irq, int flag)
 {
 	struct msi_desc *entry;

@@ -154,11 +177,13 @@ void write_msi_msg(unsigned int irq, str
 void mask_msi_irq(unsigned int irq)
 {
 	msi_set_mask_bit(irq, 1);
+	msix_flush_writes(irq);
 }
 
 void unmask_msi_irq(unsigned int irq)
 {
 	msi_set_mask_bit(irq, 0);
+	msix_flush_writes(irq);
 }
 
 static int msi_free_irq(struct pci_dev* dev, int irq);

Sorry, but this isn't going to go into 2.6.20 any time soon as it doesn't fit the rules for the -stable tree.

But I'll take an updated version for my pci tree to go to Linus after 2.6.21 is out.

thanks,

greg k-h

Oh nevermind, you already sent me that one...

thanks,

greg k-h

Greg this does fix a bug that affects 2.6.21. We have hardware in 2.6.21 that is affected And it at least seems to meet the obviously correct criteria. So at least for 2.6.21 I think it is interesting.

Eric

We do? What hardware has this reported problem showed up on? I haven't seen any bug reports yet.

And I think it's way too late for something like this. If it's really needed, I don't have a problem adding it to the 2.6.21-stable tree in a few weeks.

thanks,

greg k-h