public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Greg KH" <gregkh@suse.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	<linux-pci@atrey.karlin.mff.cuni.cz>,
	<linux-kernel@vger.kernel.org>,
	"Kok, Auke-jan H" <auke-jan.h.kok@intel.com>,
	"Williams, Mitch A" <mitch.a.williams@intel.com>
Subject: [PATCH] msi: Immediately mask and unmask msi-x irqs.
Date: Tue, 03 Apr 2007 01:41:49 -0600	[thread overview]
Message-ID: <m1lkh9dhvm.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <08FE5CC30C9A3F41BF819A502CF7BF6E0100376E@fmsmsx411.amr.corp.intel.com> (Mitch A. Williams's message of "Fri, 30 Mar 2007 13:49:20 -0700")


This is a simplified and actually more comprehensive form of a bug
fix from Mitch Williams <mitch.a.williams@intel.com>.

When we mask or unmask a msi-x irqs the writes may be posted because
we are writing to memory mapped region.  This means the mask and
unmask don't happen immediately but at some unspecified time in the
future.  Which is out of sync with how the mask/unmask logic work
for ioapic irqs.

The practical result is that we get very subtle and hard to track down
irq migration bugs.

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.

The testing by Mitch Williams on his especially problematic system should
still be valid as I have only simplified the code, not changed the
functionality.

We currently have 7 drivers: cciss, mthca, cxgb3, forceth, s2io,
pcie/portdrv_core, and qla2xxx in 2.6.21 that are affected by this
problem when the hardware they driver is plugged into the right slot.

Given the difficulty of reproducing this bug and tracing it down to
anything that even remotely resembles a cause, even if people are
being affected we aren't likely to see many meaningful bug reports, and
the people who see this bug aren't likely to be able to reproduce this
bug in a timely fashion.  So it is best to get this problem fixed 
as soon as we can so people don't have problems.

Then if people do have a kernel message stating "No irq for vector" we
will know it is yet another novel cause that needs a complete new
investigation.

So here is a one liner that will hopefully be a part of 2.6.21.

Cc: Mitch Williams <mitch.a.williams@intel.com>
Cc: Greg KH <greg@kroah.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 drivers/pci/msi.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index ad33e01..435c195 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -94,6 +94,7 @@ static void msi_set_mask_bit(unsigned int irq, int flag)
 		int offset = entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
 			PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET;
 		writel(flag, entry->mask_base + offset);
+		readl(entry->mask_base + offset);
 		break;
 	}
 	default:
-- 
1.5.0.4


  parent reply	other threads:[~2007-04-03  7:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-30 18:54 [PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3) Mitch Williams
2007-03-30 19:04 ` Eric W. Biederman
2007-03-30 19:47   ` Andrew Morton
2007-03-30 19:49     ` Greg KH
2007-03-30 20:00       ` Andrew Morton
2007-03-30 20:10         ` Greg KH
2007-03-30 20:21           ` Williams, Mitch A
2007-03-30 20:24             ` Greg KH
2007-03-30 20:26       ` Eric W. Biederman
2007-03-30 20:49         ` Williams, Mitch A
2007-03-30 20:56           ` Chuck Ebbert
2007-03-30 21:05           ` Eric W. Biederman
2007-04-03  7:41           ` Eric W. Biederman [this message]
2007-04-03 17:24             ` [PATCH] msi: Immediately mask and unmask msi-x irqs Williams, Mitch A
2007-04-03 18:52             ` Siddha, Suresh B
2007-04-03 19:39               ` Eric W. Biederman
2007-04-03 20:57                 ` Siddha, Suresh B

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=m1lkh9dhvm.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=auke-jan.h.kok@intel.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=mitch.a.williams@intel.com \
    --cc=torvalds@linux-foundation.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