linux-kernel - Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free

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

Message-ID: <alpine.DEB.2.11.1607261202250.19896@nanos>
Date:	Tue, 26 Jul 2016 13:01:59 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Auger Eric <eric.auger@...hat.com>
cc:	eric.auger.pro@...il.com, Marc Zyngier <marc.zyngier@....com>,
	christoffer.dall@...aro.org, andre.przywara@....com,
	robin.murphy@....com, alex.williamson@...hat.com,
	will.deacon@....com, joro@...tes.org,
	Jason Cooper <jason@...edaemon.net>,
	LAK <linux-arm-kernel@...ts.infradead.org>, drjones@...hat.com,
	kvmarm@...ts.cs.columbia.edu, kvm@...r.kernel.org,
	pbonzini@...hat.com, LKML <linux-kernel@...r.kernel.org>,
	Bharat.Bhushan@...escale.com, pranav.sawargaonkar@...il.com,
	p.fedin@...sung.com, iommu@...ts.linux-foundation.org,
	Jean-Philippe.Brucker@....com, yehuday@...vell.com,
	Manish.Jaggi@...iumnetworks.com, robert.richter@...iumnetworks.com,
	Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on
 msi_domain_alloc/free_irqs

On Tue, 26 Jul 2016, Auger Eric wrote:
> On 26/07/2016 11:00, Thomas Gleixner wrote:
> > In your case you don't want to have a partial allocation, so instead of
> > playing silly games with desc->irq you should add a flag which tells the PCI
> > code that you are not interested in a partial allocation and that it should
> > return an error code instead.
> 

> In that case can we consider we even succeeded in allocating 1 MSI? In case
> the IOMMU mapping fails, the MSI transaction will never reach the target MSI
> frame so it is not usable. So when you mean "partial" I understand we did
> not succeed in allocating maxvec IRQs, correct? Here we succeeded in
> allocating 0 IRQ and still msi_capability_init returns 1.
>
> msi_capability_init doc-comment says "a positive return value indicates the
> number of interrupts which could have been allocated."
> 
> I understand allocation success currently only depends on the fact virq was
> allocated and set to desc->irq. But with that IOMMU stuff doesn't the
> criteria changes?

Right. But then you need to express it differently in a consistent way. Not by
hacking around it by setting desc->irq to 0.

Something like a flag field in msi_desc which denotes various properties would
be a possible solution. MSI_IRQ_ALLOCATED and MSI_IRQ_REMAPPED would be
sufficient for now. And the deallocation/cleanup would rely on those flags
rather than checking desc->irq.

Thanks,

	tglx