Re: [PATCH 2.6.20.3] Flush writes to MSI-X table

[Greg KH <gregkh@suse.de>]

On Fri, Mar 23, 2007 at 02:50:45PM -0700, Kok, Auke wrote:
> Greg KH wrote:
> >On Thu, Mar 22, 2007 at 02:08:19PM -0700, Mitch Williams wrote:
> >>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
> >>enable/disable and rebalancing operations.  Because this is an expensive
> >>operation, we do not perform the read flush after mask/unmask
> >>operations.  Hardware which supports MSI-X typically also supports some
> >>sort of interrupt moderation, so a read-flush is not necessary for
> >>mask/unmask operations.
> >>
> >>This patch has been validated with (unreleased) network hardware which
> >>uses MSI-X.
> >
> >Is this needed for any hardware that is public today?
> 
> yes. Every msi-x capable piece of hardware in the field will crash if it 
> does any form of interrupt balancing. (okay that is not that much stuff out 
> there... I know, but the patch is not that big at all - all it does is 
> subtly add a few read flushes to make sure that critical changes in the 
> msix vector tables are pushed out at the proper time).
> 
> >Also, it seems a bit too big of a patch for -stable right now,
> >especially as the mainline patch will not make it into 2.6.22 at the
> >earliest.
> 
> I think Mitch was way too sensitive when he worded his e-mail. We should 
> really be trying to get this fix into 2.6.21 at least.
> 
> Mitch, can you re-post this and include Eric Biederman, linux-pci, our 
> intel platform guys and perhaps Linus and Andrew?
> 
> A lot of vendors (not just us) will be pushing msi-x capable hardware out, 
> and this fix is absolutely needed. Getting it in soon is really preferred. 
> Not to mention that Mitch has spent well over 8 weeks I think making sure 
> that this is indeed the issue and the proper fix...

Well, I'm sure you can agree that it is _very_ late in the 2.6.21
release cycle to expect to get this in for that kernel.  How about
waiting for 2.6.22 and if it's a big deal, getting it into the
2.6.21-stable tree if needed.

So far I have not seen any bug reports that this patch would fix, have
you?

thanks,

greg k-h