linux-kernel - Regression in 3.10.80 vs. 3.10.79

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-next>] [day] [month] [year] [list]

Message-ID: <CAL1RGDV6hr3_Oa6O-kPzx9EemtOWWtYq+-RkCzN7axNPLz5MJw@mail.gmail.com>
Date:	Tue, 9 Jun 2015 16:43:59 -0700
From:	Roland Dreier <roland@...estorage.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	George McCollister <george.mccollister@...il.com>
Subject: Regression in 3.10.80 vs. 3.10.79

Hi, I recently updated from 3.10.79 to 3.10.80, and my system wouldn't
boot any more.  I tracked this down to commit 92c934b10ec3 ("ACPI /
init: Fix the ordering of acpi_reserve_resources()").  With that
commit reverted, my system is OK again.

What happens is that ahci fails to initialize because
pcim_iomap_regions_request_all() fails with EBUSY, due to a resource
conflict on the first IO region of the ahci device.  Since my root
device is on ahci, that's the end of that.  I'm sure this is due to a
BIOS / ACPI table bug on my particular platform, but that's scant
comfort when the system won't boot :)

I patched 3.10.80 so that ahci continues to initialize after the
EBUSY, and relevant parts of the kernel log seem to be:

[    3.836643,26] system 00:06: [io  0x0400-0x047f] could not be reserved
...
[    3.844112,26] pci 0000:00:1f.2: BAR 0: assigned [io  0x0410-0x0417]
...
[    6.020040,00] ahci 0000:00:1f.2: BAR 0: can't reserve [io  0x0410-0x0417]

and /proc/ioports shows

    0410-0415 : ACPI CPU throttle

So if I'm understanding properly, for some reason we discover but fail
to reserve the region with the ACPI resources, then PCI decides to
assign ahci IO ports into that range, then ACPI loads and reserves
0x0410-0x0415, and then ahci fails to load.

If I fully revert the patch, then I see

[    3.853857,08] system 00:06: [io  0x0400-0x047f] has been reserved
...
[    3.861806,08] pci 0000:00:1f.2: BAR 0: assigned [io  0x0820-0x0827]

We're able to reserve the range, and then PCI assigns ahci into a
non-conflicting range.

I understand that the change here fixed another regression, but I'm
wondering if there's a way to make everyone happy here?  I can provide
debugging info from my system as required...

Thanks,
  Roland
--
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/