linux-kernel - Re: BAR 14: can't assign mem (size 0x200000)

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 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:	Sat, 29 Mar 2014 11:19:03 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Parag Warudkar <parag.lkml@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>, linux-pci@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: BAR 14: can't assign mem (size 0x200000)

[+cc Rafael, linux-pci, linux-acpi]

On Sat, Mar 29, 2014 at 09:41:20AM -0700, Linus Torvalds wrote:
> On Sat, Mar 29, 2014 at 12:11 AM, Yinghai Lu <yinghai@...nel.org> wrote:
> >
> > Later during resuming, kernel try to assign resource 02:00.0 but it will fail
> > as parent bridge 00:1c.3 has no resource.
> > (Not sure how pci_configure_slot get called with this resume path).
> 
> I think that last comment is the most pertinent one: why does resume
> try to assign resources to PCI devices? It should be *restoring* them,
> not re-assigning any resources.
> 
> Parag, can you add a WARN_ON_ONCE() to that message, so that we see
> what the call chain is for it.

I think we likely get a Bus Check notification when resuming, so we're
probably in this path:

    acpi_hotplug_notify_cb
      acpi_hotplug_execute(acpi_device_hotplug, ...)
	acpi_device_hotplug
	  acpi_scan_bus_check
	    acpi_pci_root_scan_dependent        # .hotplug.scan_dependent
	      acpiphp_check_host_bridge
		acpiphp_check_bridge    
		  enable_slot
		    pcibios_resource_survey_bus
		      dev_printk("Allocating resources")

It seems like we ought to do the equivalent of a Bus Check from the
root at boot-time, even if we don't receive an explicit Bus Check
notification then (ACPI 5.0, sec 5.6.6, says "OSPM will typically
perform a full enumeration automatically at boot time, but after
system initialization it is the responsibility of the ACPI AML code to
notify OSPM whenever a re-enumeration operation is required"), but I
don't think we do, which makes the resume path different from the boot
path.

Parag, would you mind collecting an acpidump and attaching it to the
bugzilla below?

Is this a regression?  I guess you said that the message (and the sec-
latency change, which I don't think is applicable to PCIe anyway) are
the only ill effects you see, so it might not be too serious even if
it is.

I am concerned about the VT-d connection and the sec-latency change.
I wouldn't be surprised to find that the resume path doesn't restore
sec-latency, but I don't know why VT-d would affect the resource
allocation.  I guess it's possible that enabling VT-d might change
the ACPI namespace; maybe you could collect *two* acpidumps: one with
VT-d enabled and another with it disabled.

Let's continue the discussion in email, but I did open
https://bugzilla.kernel.org/show_bug.cgi?id=73141 as a place to archive
your logs.

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/