linux-kernel - Re: [Bugfix] x86/PCI: Release PCI IRQ resource only if PCI device is disabled when unbinding

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]

Date:	Fri, 20 Mar 2015 08:11:26 -0500
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Jiang Liu <jiang.liu@...ux.intel.com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Alex Williamson <alex.williamson@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Thomas Hellstrom <thellstrom@...are.com>,
	"bp @ alien8 . de" <bp@...en8.de>, Lv Zheng <lv.zheng@...el.com>,
	"yinghai @ kernel . org" <yinghai@...nel.org>,
	"lenb @ kernel . org" <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [Bugfix] x86/PCI: Release PCI IRQ resource only if PCI device is
 disabled when unbinding

On Thu, Mar 19, 2015 at 10:09 PM, Jiang Liu <jiang.liu@...ux.intel.com> wrote:
> On 2015/3/19 22:08, Bjorn Helgaas wrote:

>> There are two other possibilities I can see:
>>
>> 1) Decide that a driver that captures the IRQ and then calls
>> pci_enable_device() is just broken, and fix those drivers to
>> re-capture the IRQ every time they call pci_enable_device().  I assume
>> you've looked at this already and concluded it's not practical?

Did you look at this or not?  I don't have any idea of the scope of the problem.

I think in general we want drivers to start from scratch whenever they
call pci_enable_device().  They should not assume that BARs are the
same, IRQs are the same, etc.  If we ever want to dynamically reassign
resources, e.g., move BARs around to accommodate new hotplugged
devices, a path involving pci_enable_device() seems a likely route of
having the drivers learn about resource changes.

>> 2) Configure the IRQ in pci_device_probe().  Then it would be
>> configured before the driver sees the device, and you could dispose of
>> it in pci_device_remove() when the driver is unbound.
> Actually I prefer solution 2 above. The key idea is to decouple
> IRQ resource allocation from pci_enabe/disable_device(), so irq
> resource will be allocated just before driver binding and will
> be released after driver unbinding.

Solution 2 does have the advantage of making it simpler for driver writers.

One disadvantage is that it *forces* us to do IRQ allocation, even
though it may not be required.  There are drivers that don't need IRQs
because they use MSI or don't need interrupts at all.  If we do IRQ
allocation before binding the driver, and the allocation fails, these
driver will no longer work even though they don't need the IRQs.

> One issue left is the way to hook driver binding/unbinding events.
> Currently pcibios_enable/disable_irq() are x86 specific, so I use
> PCI notification to hook driver binding/unbinding evetns.
> If you are OK with introducing two new weak functions
> pcibios_enable/disable_irq() into PCI core, that's obviously
> a clear solution, easier to maintain and may benefit other platforms
> too in future.
>
> So should I introduce pcibios_enable/disable_irq() into PCI core?

I think it would be better to add new weak interfaces than to use
bus_register_notifier().  New interfaces are much more explicit when
reading the code, and their ordering is very clearly defined.

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