linux-kernel - Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi

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: <20131002023337.GB22748@concordia>
Date:	Wed, 2 Oct 2013 12:33:38 +1000
From:	Michael Ellerman <michael@...erman.id.au>
To:	Tejun Heo <tj@...nel.org>
Cc:	Alexander Gordeev <agordeev@...hat.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>, Joerg Roedel <joro@...tes.org>,
	Jan Beulich <JBeulich@...e.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

On Tue, Oct 01, 2013 at 07:55:03AM -0400, Tejun Heo wrote:
> Hello,
> 
> On Tue, Oct 01, 2013 at 05:35:48PM +1000, Michael Ellerman wrote:
> > > > Roughly third of the drivers just do not care and bail out once
> > > > pci_enable_msix() has not succeeded. Not sure how many of these are
> > > > mandated by the hardware.
> > > 
> > > Yeah, I mean, this type of interface is a trap.  People have to
> > > actively resist to avoid doing silly stuff which is a lot to ask.
> > 
> > I really think you're overstating the complexity here.
> > 
> > Functions typically return a boolean   -> nothing to see here
> > This function returns a tristate value -> brain explosion!
> 
> It is an interface which forces the driver writers to write
> complicated fallback code which won't usually be excercised.  

It does not force anyone to do anything. That's just bull.

Code which is unwilling or unable to cope with the extra complexity
can simply do:

if (pci_enable_msix(..))
	goto fail;

It's as simple as that.

> > > * Determine the number of MSIs the controller wants.  Don't worry
> > >   about quotas or limits or anything.  Just determine the number
> > >   necessary to enable enhanced interrupt handling.
> > > 	
> > > * Try allocating that number of MSIs.  If it fails, then just revert
> > >   to single interrupt mode.  It's not the end of the world and mostly
> > >   guaranteed to work.  Let's please not even try to do partial
> > >   multiple interrupts.  I really don't think it's worth the risk or
> > >   complexity.
> > 
> > It will potentially break existing setups on our hardware.
> 
> I think it'd be much better to have a separate interface for the
> drivers which actually require it *in practice* rather than forcing
> everyone to go "oh this interface supports that, I don't know if I
> need it but let's implement fallback logic which I won't and have no
> means of testing".  

Sure, that's easy:

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d5f90d6..48d0252 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -988,6 +988,18 @@ int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
 }
 EXPORT_SYMBOL(pci_enable_msix);
 
+int pci_enable_msix_or_fail(struct pci_dev *dev, struct msix_entry *entries,
+                           int nvec)
+{
+       int rc;
+
+       rc = pci_enable_msix(dev, entries, nvec);
+       if (rc > 0)
+               rc = -ENOSPC;
+
+       return rc;
+}
+
 void pci_msix_shutdown(struct pci_dev *dev)
 {
        struct msi_desc *entry;


> Are we talking about some limited number of device drivers here?  

I don't have a list, but yeah there are certain drivers that folks care about.

> Also, is the quota still necessary for machines in production today?

As far as I know yes. The number of MSIs is growing on modern systems, but so
is the number of cpus and devices.

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