linux-kernel - Re: [PATCH 24/25] PCI: Perform reset_resource() and build fail list in sync

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: <e54e87cb-5f40-4e7e-8f88-fb08746b701b@roeck-us.net>
Date: Tue, 1 Apr 2025 06:28:51 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
 Michał Winiarski <michal.winiarski@...el.com>,
 Igor Mammedov <imammedo@...hat.com>, LKML <linux-kernel@...r.kernel.org>,
 Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 24/25] PCI: Perform reset_resource() and build fail list
 in sync

On 4/1/25 03:18, Ilpo Järvinen wrote:
> On Mon, 31 Mar 2025, Guenter Roeck wrote:
>> On Mon, Dec 16, 2024 at 07:56:31PM +0200, Ilpo Järvinen wrote:
>>> Resetting resource is problematic as it prevent attempting to allocate
>>> the resource later, unless something in between restores the resource.
>>> Similarly, if fail_head does not contain all resources that were reset,
>>> those resource cannot be restored later.
>>>
>>> The entire reset/restore cycle adds complexity and leaving resources
>>> into reseted state causes issues to other code such as for checks done
>>> in pci_enable_resources(). Take a small step towards not resetting
>>> resources by delaying reset until the end of resource assignment and
>>> build failure list (fail_head) in sync with the reset to avoid leaving
>>> behind resources that cannot be restored (for the case where the caller
>>> provides fail_head in the first place to allow restore somewhere in the
>>> callchain, as is not all callers pass non-NULL fail_head).
>>>
>>> The Expansion ROM check is temporarily left in place while building the
>>> failure list until the upcoming change which reworks optional resource
>>> handling.
>>>
>>> Ideally, whole resource reset could be removed but doing that in a big
>>> step would make the impact non-tractable due to complexity of all
>>> related code.
>>>
>>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
>>
>> With this patch in the mainline kernel, all mips:boston qemu emulations
>> fail when running a 64-bit little endian configuration (64r6el_defconfig).
>>
>> The problem is that the PCI based IDE/ATA controller is not initialized.
>> There are a number of pci error messages.
>>
>> pci_bus 0002:01: extended config space not accessible
>> pci 0002:01:00.0: [8086:2922] type 00 class 0x010601 conventional PCI endpoint
>> pci 0002:01:00.0: BAR 4 [io  0x0000-0x001f]
>> pci 0002:01:00.0: BAR 5 [mem 0x00000000-0x00000fff]
>> pci 0002:00:00.0: PCI bridge to [bus 01-ff]
>> pci_bus 0002:01: busn_res: [bus 01-ff] end is updated to 01
>> pci 0002:00:00.0: bridge window [mem 0x16000000-0x160fffff]: assigned
>> pci 0002:00:00.0: bridge window [mem size 0x00100000 64bit pref]: can't assign; no space
>> pci 0002:00:00.0: bridge window [mem size 0x00100000 64bit pref]: failed to assign
>> pci 0002:00:00.0: bridge window [io  size 0x1000]: can't assign; no space
>> pci 0002:00:00.0: bridge window [io  size 0x1000]: failed to assign
>> pci 0002:00:00.0: bridge window [mem size 0x00100000]: can't assign; bogus alignment
>> pci 0002:00:00.0: bridge window [mem 0x16000000-0x160fffff 64bit pref]: assigned
>> pci 0002:00:00.0: bridge window [io  size 0x1000]: can't assign; no space
>> pci 0002:00:00.0: bridge window [io  size 0x1000]: failed to assign
>> pci 0002:01:00.0: BAR 5 [mem size 0x00001000]: can't assign; no space
>> pci 0002:01:00.0: BAR 5 [mem size 0x00001000]: failed to assign
>> pci 0002:01:00.0: BAR 4 [io  size 0x0020]: can't assign; no space
>> pci 0002:01:00.0: BAR 4 [io  size 0x0020]: failed to assign
>> pci 0002:01:00.0: BAR 5 [mem size 0x00001000]: can't assign; no space
>> pci 0002:01:00.0: BAR 5 [mem size 0x00001000]: failed to assign
>> pci 0002:01:00.0: BAR 4 [io  size 0x0020]: can't assign; no space
>> pci 0002:01:00.0: BAR 4 [io  size 0x0020]: failed to assign
>> pci 0002:00:00.0: PCI bridge to [bus 01]
>> pci 0002:00:00.0:   bridge window [mem 0x16000000-0x160fffff 64bit pref]
>> pci_bus 0002:00: Some PCI device resources are unassigned, try booting with pci=realloc
>> pci_bus 0002:00: resource 4 [mem 0x16000000-0x160fffff]
>> pci_bus 0002:01: resource 2 [mem 0x16000000-0x160fffff 64bit pref]
>> ...
>> pci 0002:00:00.0: enabling device (0000 -> 0002)
>> ahci 0002:01:00.0: probe with driver ahci failed with error -12
>>
>> Bisect points to this patch. Reverting it together with "PCI: Rework
>> optional resource handling" fixes the problem. For comparison, after
>> reverting the offending patches, the log messages are as follows.
>>
>> pci_bus 0002:00: root bus resource [bus 00-ff]
>> pci_bus 0002:00: root bus resource [mem 0x16000000-0x160fffff]
>> pci 0002:00:00.0: [10ee:7021] type 01 class 0x060400 PCIe Root Complex Integrated Endpoint
>> pci 0002:00:00.0: PCI bridge to [bus 00]
>> pci 0002:00:00.0:   bridge window [io  0x0000-0x0fff]
>> pci 0002:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
>> pci 0002:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
>> pci 0002:00:00.0: enabling Extended Tags
>> pci 0002:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>> pci_bus 0002:01: extended config space not accessible
>> pci 0002:01:00.0: [8086:2922] type 00 class 0x010601 conventional PCI endpoint
>> pci 0002:01:00.0: BAR 4 [io  0x0000-0x001f]
>> pci 0002:01:00.0: BAR 5 [mem 0x00000000-0x00000fff]
>> pci 0002:00:00.0: PCI bridge to [bus 01-ff]
>> pci_bus 0002:01: busn_res: [bus 01-ff] end is updated to 01
>> pci 0002:00:00.0: bridge window [mem 0x16000000-0x160fffff]: assigned
>> pci 0002:00:00.0: bridge window [mem size 0x00100000 64bit pref]: can't assign; no space
>> pci 0002:00:00.0: bridge window [mem size 0x00100000 64bit pref]: failed to assign
>> pci 0002:00:00.0: bridge window [io  size 0x1000]: can't assign; no space
>> pci 0002:00:00.0: bridge window [io  size 0x1000]: failed to assign
>> pci 0002:01:00.0: BAR 5 [mem 0x16000000-0x16000fff]: assigned
>> pci 0002:01:00.0: BAR 4 [io  size 0x0020]: can't assign; no space
>> pci 0002:01:00.0: BAR 4 [io  size 0x0020]: failed to assign
>> pci 0002:00:00.0: PCI bridge to [bus 01]
>> pci 0002:00:00.0:   bridge window [mem 0x16000000-0x160fffff]
>> pci_bus 0002:00: Some PCI device resources are unassigned, try booting with pci=realloc
>> pci_bus 0002:00: resource 4 [mem 0x16000000-0x160fffff]
>> pci_bus 0002:01: resource 1 [mem 0x16000000-0x160fffff]
>> ...
>> pci 0002:00:00.0: enabling device (0000 -> 0002)
>> ahci 0002:01:00.0: enabling device (0000 -> 0002)
>> ahci 0002:01:00.0: AHCI vers 0001.0000, 32 command slots, 1.5 Gbps, SATA mode
>> ahci 0002:01:00.0: 6/6 ports implemented (port mask 0x3f)
>> ahci 0002:01:00.0: flags: 64bit ncq only
> 
> Hi,
> 
> Thanks for reporting. Please add this to the command line to get the
> resource releasing between the steps to show:
> 
> dyndbg="file drivers/pci/setup-bus.c +p"
> 
> Also, the log snippet just shows it fails but it is impossible to know
> from it why the resource assigments do not fit so could you please provide
> a complete dmesg logs. Also providing the contents of /proc/iomem from the
> working case would save me quite a bit of decoding the iomem layout from
> the dmesgs.
> 

You should find everything you need at http://server.roeck-us.net/qemu/mipsel64/.
Please let me know if you need anything else.

Thanks,
Guenter