linux-kernel - Re: [PATCH] x86/PCI: Fully disable devices before releasing IRQ resource

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: <6862626.yP8c2o2fAj@vostro.rjw.lan>
Date:	Thu, 12 Mar 2015 02:17:15 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Alex Williamson <alex.williamson@...hat.com>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"bp@...en8.de" <bp@...en8.de>, "Zheng, Lv" <lv.zheng@...el.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"yinghai@...nel.org" <yinghai@...nel.org>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/PCI: Fully disable devices before releasing IRQ resource

On Wednesday, March 11, 2015 10:04:42 PM Luck, Tony wrote:
> >> Unfortunately there's a long standing comment in pci_device_remove():
> >> 
> >>         /*
> >>          * We would love to complain here if pci_dev->is_enabled is set, that
> >>          * the driver should have called pci_disable_device(), but the
> >>          * unfortunate fact is there are too many odd BIOS and bridge setups
> >>          * that don't like drivers doing that all of the time.
> >>          * Oh well, we can dream of sane hardware when we sleep, no matter how
> >>          * horrible the crap we have to deal with is when we are awake...
> >>          */
> >> 
> >> So, unless we can somehow ignore that comment, I suspect forcing the
> >> device to be disabled on driver remove, whether done from pci-core or
> >> from x86/pci, is going to cause all sorts of breakage.  Are the
> >> expectations set by b4b55cda5874 really valid?  It seems like something
> >> needs to be done to allow the IRQ to be automatically re-established on
> >> x86 regardless of the driver doing the right thing when releasing the
> >> device.  We're still looking at a regression for v4.0 as a result of
> >> b4b55cda5874.
> >
> > In which case we probably should revert commit b4b55cda5874 for the time being.
> >
> > At least I'd be very nervous about any ad-hoc fixes at this stage of the cycle.
> 
> The comment goes back to the dawn of "git" time ... not sure how much further
> back.
> 
> Is this actually still an issue on modern systems?  Maybe we need a black list
> or white list to separate the good from bad systems?

The answer to that is "We don't know" and in my not so humble opinion it is too
risky to try to find out at the end of the cycle.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/