linux-kernel - Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

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: <20131008122215.GA14389@dhcp-26-207.brq.redhat.com>
Date:	Tue, 8 Oct 2013 14:22:16 +0200
From:	Alexander Gordeev <agordeev@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ben Hutchings <bhutchings@...arflare.com>,
	linux-kernel@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Michael Ellerman <michael@...erman.id.au>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Ingo Molnar <mingo@...hat.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Andy King <acking@...are.com>, Jon Mason <jon.mason@...el.com>,
	Matt Porter <mporter@...nel.crashing.org>,
	linux-pci@...r.kernel.org, linux-mips@...ux-mips.org,
	linuxppc-dev@...ts.ozlabs.org, linux390@...ibm.com,
	linux-s390@...r.kernel.org, x86@...nel.org,
	linux-ide@...r.kernel.org, iss_storagedev@...com,
	linux-nvme@...ts.infradead.org, linux-rdma@...r.kernel.org,
	netdev@...r.kernel.org, e1000-devel@...ts.sourceforge.net,
	linux-driver@...gic.com,
	Solarflare linux maintainers <linux-net-drivers@...arflare.com>,
	"VMware, Inc." <pv-drivers@...are.com>, linux-scsi@...r.kernel.org
Subject: Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement
 pattern

On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote:
> > What about introducing pci_lock_msi() and pci_unlock_msi() and let device
> > drivers care about their ranges and specifics in race-safe manner?
> > I do not call to introduce it right now (since it appears pSeries has not
> > been hitting the race for years) just as a possible alternative to Ben's
> > proposal.
> 
> I don't think the same race condition would happen with the loop.

We need to distinguish the contexts we're discussing.

If we talk about pSeries quota, then the current pSeries pci_enable_msix()
implementation is racy internally and could fail if the quota went down
*while* pci_enable_msix() is executing. In this case the loop will have to
exit rather than retry with a lower number (what number?).

In this regard the new scheme does not bring anything new and relies on
the fact this race does not hit and therefore does not worry.

If we talk about quota as it has to be, then yes - the loop scheme seems
more preferable.

Overall, looks like we just need to fix the pSeries implementation,
if the guys want it, he-he :)

> The problem case is where multiple msi(x) allocation fails completely
> because the global limit went down before inquiry and allocation.  In
> the loop based interface, it'd retry with the lower number.

I am probably missing something here. If the global limit went down before
inquiry then the inquiry will get what is available and try to allocate with
than number.

-- 
Regards,
Alexander Gordeev
agordeev@...hat.com
--
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/