linux-kernel - Re: [PATCH] x86 PCI: Do not use interrupt links for devices using MSI-X

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

Message-Id: <200901051450.28310.rjw@sisk.pl>
Date:	Mon, 5 Jan 2009 14:50:27 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86 PCI: Do not use interrupt links for devices using MSI-X

On Monday 05 January 2009, Ingo Molnar wrote:
> 
> * Rafael J. Wysocki <rjw@...k.pl> wrote:
> 
> > From: Rafael J. Wysocki <rjw@...k.pl>
> > 
> > pcibios_enable_device() and pcibios_disable_device() don't handle
> > IRQs for devices that have MSI enabled and it should tread the
> 
> s/tread/treat

Ah, thanks.

> > devices with MSI-X enabled in the same way.
> > 
> > Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
> > ---
> >  arch/x86/pci/common.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> looks good - Jesse, what do you think?
> 
> Rafael, i'm curious is this in response to some regression/bug? Did some 
> box or driver get confused by us enabling/disabling the GSI? Some IRQ 
> flood perhaps?

Well, I don't have any MSI-X capable boxes around. :-)

I was just reviewing the code and spotted this.

> btw., there's a small observation:
> 
> > +     if (!dev->msi_enabled && !dev->msix_enabled)
> 
> maybe a "pci_has_gsi_irq()" wrapper would make these checks cleaner and 
> would make things more robust, should there be any new IRQ delivery method 
> be introduced in the future?

Well, perhaps something like the patch below?

Thanks,
Rafael

---
Subject: x86 PCI: Do not use interrupt links for devices using MSI-X (rev. 2)
From: Rafael J. Wysocki <rjw@...k.pl>

pcibios_enable_device() and pcibios_disable_device() don't handle
IRQs for devices that have MSI enabled and it should treat the
devices with MSI-X enabled in the same way.

Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
---
 arch/x86/pci/common.c |    4 ++--
 include/linux/pci.h   |    9 +++++++++
 2 files changed, 11 insertions(+), 2 deletions(-)

Index: linux-2.6/arch/x86/pci/common.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/common.c
+++ linux-2.6/arch/x86/pci/common.c
@@ -551,14 +551,14 @@ int pcibios_enable_device(struct pci_dev
 	if ((err = pci_enable_resources(dev, mask)) < 0)
 		return err;
 
-	if (!dev->msi_enabled)
+	if (!pci_msi_enabled(dev))
 		return pcibios_enable_irq(dev);
 	return 0;
 }
 
 void pcibios_disable_device (struct pci_dev *dev)
 {
-	if (!dev->msi_enabled && pcibios_disable_irq)
+	if (!pci_msi_enabled(dev) && pcibios_disable_irq)
 		pcibios_disable_irq(dev);
 }
 
Index: linux-2.6/include/linux/pci.h
===================================================================
--- linux-2.6.orig/include/linux/pci.h
+++ linux-2.6/include/linux/pci.h
@@ -274,6 +274,15 @@ static inline void pci_add_saved_cap(str
 	hlist_add_head(&new_cap->next, &pci_dev->saved_cap_space);
 }
 
+#ifdef CONFIG_PCI_MSI
+static inline bool pci_msi_enabled(struct pci_dev *pci_dev)
+{
+	return dev->msi_enabled || dev->msix_enabled;
+}
+#else
+static inline bool pci_msi_enabled(struct pci_dev *pci_dev) { return false; }
+#endif
+
 /*
  *  For PCI devices, the region numbers are assigned this way:
  *

--
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/