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: <f2d149c6-41a4-4a9a-9739-1ea1c4b06f4b@linaro.org>
Date: Mon, 2 Jun 2025 19:42:58 +0100
From: Tudor Ambarus <tudor.ambarus@...aro.org>
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>,
 William McVicker <willmcvicker@...gle.com>
Subject: Re: [PATCH 24/25] PCI: Perform reset_resource() and build fail list
 in sync



On 6/2/25 4:08 PM, Ilpo Järvinen wrote:
>>> I think I figured out more about the reason. It's not related to that 
>>> bridge window resource.
>>>
>>> pbus_size_mem() will add also that ROM resource into realloc_head 
>>> as it is considered (intentionally) optional after the optional change
>>> (as per "tudor: 2:" line). And that resource is never assigned because 

cut

>>> pdev_sort_resources() didn't pick it up into the head list. The next 
>>> question is why the ROM resource isn't in the head list.
>>>
>> It seems the ROM resource is skipped at:
>> https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-
>> next.git/tree/drivers/pci/setup-bus.c#n175
>>
>> tudor: pdev_sort_resources: ROM [??? 0x00000000 flags 0x0] resource
>> skipped due to !(r->flags) || r->parent
> I don't see the device in this print, hope it is for the same device.
> 
> In any case, I don't understand what reset resource's flags in between 
> pbus_size_mem() and pdev_sort_resources(), or alternative, why type 
> checking in pbus_size_mem() matches if flags == 0 at that point.
> 
> Those two functions should work on the same resources, if one skips 
> something, the other should too. Disparity between them can cause issues, 
> but despite reading the code multiple times, I couldn't figure out how 
> that disparity occurs (except for the !pdev_resources_assignable() case).

cut

> It is of interest to know why the same resource is treated differently.
> So what were the resource flags, type* args when it's processed by
> pbus_size_mem()? If resource's flags are zero at that point but it matches 

This is the full output: https://termbin.com/mn1x
for the following prints: https://termbin.com/q57h

It seems ROM resource is of type 2 at pbus_size_mem() time.

> one of the types, that would be a bug.

I'll give another try tomorrow. Thanks,
ta