linux-kernel - RE: [PATCH]: Staging: hv: Allocate the vmbus irq dynamically

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: <alpine.LFD.2.00.1102201705380.2701@localhost6.localdomain6>
Date:	Sun, 20 Feb 2011 17:15:42 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	KY Srinivasan <kys@...rosoft.com>
cc:	"gregkh@...e.de" <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Hank Janssen <hjanssen@...rosoft.com>
Subject: RE: [PATCH]: Staging: hv: Allocate the vmbus irq dynamically

On Sat, 19 Feb 2011, KY Srinivasan wrote:
> > When grabbing some random irq from the PIC is not an issue, then
> > what's the point of this probing, retry loop and the comments about
> > racing ? What races here? That does not make sense at all.
> 
> Like most virtualization platforms, Hyper-V also emulates the full PC 
> platform. So, it is possible that the driver of some other emulated
> devices might register for the IRQ line we might have selected. That 
> is the race this code addresses. For performance reasons, we want
> both storage and network traffic to go over the PV drivers. 

So in case your driver gets the interrupt line first, which the other
driver wants to acquire as well, then what? Do you want to do that
probe magic in the other driver as well? What if this is a regular
device driver which gets its irq number from ACPI/PCI or
whatever. Then that driver simply wont work as it's interrupt line is
busy.

> > 
> > I don't know why the previous reviewer wanted to have that
> > dynamic. That just does not make sense to me.
> 
> Prior to this patch, we had a hard coded interrupt line for use by
> this driver. If that line was already in use, the load of this driver 
> would fail. This would be a fatal issue especially for distributions
> that have embedded these PV drivers as part of their installation
> media. This patch deals with such collisions in a more graceful way -
> we would not bail until we have scanned all low interrupt lines.

So you trade breaking the PV stuff against breaking random other
drivers? That doesn't sound like a brilliant idea.

There are various ways to solve that proper.

 - You can provide the interrupt number from ACPI/PCI or whatever your HV
   provides as enumeration.

 - Use a fixed vector like XEN does for the event channel

 - Use dynamic allocation in the IOAPIC space like the kernel does for
   MSI(-X)

Thanks,

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