linux-kernel - Re: [PATCH] Reinstate "resource: avoid unnecessary lookups in find_next_iomem

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: <a33e119f-09b9-4cd9-a895-e3f95d659a35@kernel.org>
Date: Tue, 25 Nov 2025 09:18:52 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Ilias Stamatis <ilstam@...zon.com>, akpm@...ux-foundation.org,
 linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, nadav.amit@...il.com, huang.ying.caritas@...il.com,
 andriy.shevchenko@...ux.intel.com, bhe@...hat.com, nh-open-source@...zon.com
Subject: Re: [PATCH] Reinstate "resource: avoid unnecessary lookups in
 find_next_iomem_res()"

On 11/25/25 09:09, David Hildenbrand (Red Hat) wrote:
> On 11/24/25 17:53, Ilias Stamatis wrote:
>> Commit 97523a4edb7b ("kernel/resource: remove first_lvl / siblings_only
>> logic") removed an optimization introduced by commit 756398750e11
>> ("resource: avoid unnecessary lookups in find_next_iomem_res()"). That
>> was not called out in the message of the first commit explicitly so it's
>> not entirely clear whether removing the optimization happened
>> inadvertently or not.
> 
> Remembering the history, we have some things where the top might not
> fully describe what the lower levels do.
> 
> An example is for example found here:
> 
> Author: Dan Williams <dan.j.williams@...el.com>
> Date:   Thu Feb 16 00:36:02 2023 -0800
> 
>       dax/kmem: Fix leak of memory-hotplug resources
>       
>       While experimenting with CXL region removal the following corruption of
>       /proc/iomem appeared.
>       
>       Before:
>       f010000000-f04fffffff : CXL Window 0
>         f010000000-f02fffffff : region4
>           f010000000-f02fffffff : dax4.0
>             f010000000-f02fffffff : System RAM (kmem)
> 
> The CXL Windows will certainly not match System RAM, as one example.
> 
> How would your change affect such cases?

Looking into the details, I assume, as we only check that the actual 
range matches, not the type, that this is fine.

So yeah, that makes sense to me. I guess I removed it as part of 
97523a4edb7b by accident, when I primarily wanted to remove the 
first_lvl parameter.

Given that the above still works as expected:

Acked-by: David Hildenbrand (Red Hat) <david@...nel.org>

-- 
Cheers

David