linux-kernel - Re: [PATCH v3] ACPI: Fix osc flag setup ordering to allow pcie hotplug use when available

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:	Tue, 27 Aug 2013 19:43:45 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Len Brown <lenb@...nel.org>, "Rafael J. Wysocki" <rjw@...k.pl>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Stefan Seyfried <stefan.seyfried@...glemail.com>
Subject: Re: [PATCH v3] ACPI: Fix osc flag setup ordering to allow pcie
 hotplug use when available

On Tue, Aug 27, 2013 at 03:34:11PM -0600, Bjorn Helgaas wrote:
> [+cc Stefan]
> 
> On Mon, Aug 26, 2013 at 9:39 AM, Neil Horman <nhorman@...driver.com> wrote:
> > Somewhere between 3.9 and 3.10 it seems the order in which pcie and acpi probed
> > slots for hotplug capabilites got reversed.  While this isn't a big deal, it did
> > uncover a bug in the ACPI bus setup path.  Specifically, acpi_pci_root_add calls
> > pci_acpi_scan_root before setting the osc flags for the device handle.
> > pci_acpi_scan_root, among other things uses device_is_managed_by_native_pciehp()
> > to determine if a given slot has pcie hotplug capabilties, whcih checks the
> > devices OSC_PCI_EXPRESS_NATIVE_HP_CONTROL flag.  Since that flag is not set
> > until after pci_acpi_scan_root_completes, the acpi code never sees that pcie
> > slots are hotplug capable and configures them all to use acpi instead.
> 
> I'd like to make it more explicit what we're fixing.  Apparently this
> is a regression between v3.9 and v3.10.
> 
> Is this a fix for problems like
> https://bugzilla.kernel.org/show_bug.cgi?id=60736 ?  That bug is that
> an ExpressCard slot doesn't work unless we boot with
> "acpiphp.disable=1".  I think what happens there is that acpiphp
> claims the slot before we run _OSC, so pciehp doesn't claim it, even
> though _OSC did grant us control over native PCIe hotplug.
> 
Yes, that bug is precisely what I am trying to fix (although your wording above is
inverted from the problem in the bug).  What happens is that acpiphp claims the
pcie ports, because acpiphp init runs first, and we haven't yet parsed _OSC,
which would have told acpiphp to yield control to pciehp.  The initial fix I
proposed fixed this by parsing _OSC prior to running the acpiphp bus scan, but
that reintroduced the problem of not handling pcie 1.1 aspm properly.  That has
been fixed in v2/v3 by deferring the setting of aspm_disable until after the bus
scan.

Shall I submit a v4 with an updated changelog?

Best
Neil

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