From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8367727D77D for ; Tue, 25 Nov 2025 08:18:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764058737; cv=none; b=W2eEy0FE3pBRKR7efdx6QwD1JKjs55aUNMzhtuschXzPR1NWVT4cIymILvJbTiEPWdcpyTD2gmFIKaYKWECZrC0dqJz74y+So4pIVsDCCSAFKlqpAmjw2T+gSwn+SC4paRYlp/ULSIIOgiup/ObdGziGizd3YLLHXUe1+Mx3qao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764058737; c=relaxed/simple; bh=XYNAwhlrNrGWRmaAZUQEDrj1+kspEfhdgIAxGaDsVFY=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=aZzrIkG/aB9MOXC6qjjXr44ZPyvq+hLc2/kNQI9Dw6bZKP7T+ul2QAjaXDyJ/r71CbAGiURok01zGegJEeCgcm4rNe1Sp7gonQacphoF6W+dtjhUOBuLYXaI48ePIKUG+loqjvJnObA0kBmXfGMOnvDUo9nZWbPxl43QDSmlnl4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mvA/Z70K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mvA/Z70K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5846C4CEF1; Tue, 25 Nov 2025 08:18:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764058737; bh=XYNAwhlrNrGWRmaAZUQEDrj1+kspEfhdgIAxGaDsVFY=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=mvA/Z70Kt1JdWg9tYbtVJQb8zJvJarqaSsObCaxf4m0JRIspPMUDfKYu7NCdPEpx9 iyOfDRzvbJEKAgL7xxM4zsj0y14lm13bsZ59kI+BcdREuhoFluLhWIp6DPc2D31kJR fBfm/uQBujTHBGNLkw1UIXLeXwdHCGujOEh1ZulPdwx+33yRZb9lCeQ59WieLDSxhG g60YDYWSZ+LfxhNwAmHEwCe/P1m8n1ztq+pabXVRhpCNUOJlNo35VxGy3uHefeDKdF ryWFY9TcwTmki9tWV2JHCo2CaNVUZ9t9YfsENzKAepQ82VC8W7WD/F+c7E8/Zo2qkW B9mIHw6aWoQ8A== Message-ID: Date: Tue, 25 Nov 2025 09:18:52 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Reinstate "resource: avoid unnecessary lookups in find_next_iomem_res()" From: "David Hildenbrand (Red Hat)" To: Ilias Stamatis , akpm@linux-foundation.org, linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, nadav.amit@gmail.com, huang.ying.caritas@gmail.com, andriy.shevchenko@linux.intel.com, bhe@redhat.com, nh-open-source@amazon.com References: <20251124165349.3377826-1-ilstam@amazon.com> <9fdc1d1f-ce00-47ff-bdf5-66e8a511be25@kernel.org> Content-Language: en-US In-Reply-To: <9fdc1d1f-ce00-47ff-bdf5-66e8a511be25@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > 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) -- Cheers David