[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFqkus8o8HESv36F@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
Date: Tue, 24 Jun 2025 15:14:34 +0200
From: Alexander Gordeev <agordeev@...ux.ibm.com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-mm@...ck.org, dev.jain@....com,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Ryan Roberts <ryan.roberts@....com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org
Subject: Re: [PATCH V2] mm/ptdump: Take the memory hotplug lock inside
ptdump_walk_pgd()
On Fri, Jun 20, 2025 at 10:54:27AM +0530, Anshuman Khandual wrote:
> Memory hot remove unmaps and tears down various kernel page table regions
> as required. The ptdump code can race with concurrent modifications of the
> kernel page tables. When leaf entries are modified concurrently, the dump
> code may log stale or inconsistent information for a VA range, but this is
> otherwise not harmful.
>
> But when intermediate levels of kernel page table are freed, the dump code
> will continue to use memory that has been freed and potentially reallocated
> for another purpose. In such cases, the ptdump code may dereference bogus
> addresses, leading to a number of potential problems.
>
> To avoid the above mentioned race condition, platforms such as arm64, riscv
> and s390 take memory hotplug lock, while dumping kernel page table via the
> sysfs interface /sys/kernel/debug/kernel_page_tables.
>
> Similar race condition exists while checking for pages that might have been
> marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in
> turn calls ptdump_check_wx(). Instead of solving this race condition again,
> let's just move the memory hotplug lock inside generic ptdump_check_wx()
> which will benefit both the scenarios.
>
> Drop get_online_mems() and put_online_mems() combination from all existing
> platform ptdump code paths.
>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will@...nel.org>
> Cc: Ryan Roberts <ryan.roberts@....com>
> Cc: Paul Walmsley <paul.walmsley@...ive.com>
> Cc: Palmer Dabbelt <palmer@...belt.com>
> Cc: Alexander Gordeev <agordeev@...ux.ibm.com>
> Cc: Gerald Schaefer <gerald.schaefer@...ux.ibm.com>
> Cc: Heiko Carstens <hca@...ux.ibm.com>
> Cc: Vasily Gorbik <gor@...ux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@...ux.ibm.com>
> Cc: Sven Schnelle <svens@...ux.ibm.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> CC: linux-arm-kernel@...ts.infradead.org
> Cc: linux-kernel@...r.kernel.org
> Cc: linux-riscv@...ts.infradead.org
> Cc: linux-s390@...r.kernel.org
> Cc: linux-mm@...ck.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> ---
> This patch applies on v6.16-rc2 and has been tested on arm64. Besides it
> builds on riscv, s390, x86 and powerpc as well. But should the following
> fixes tag from V1 also needs to be around as well ?
>
> Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove")
>
> Changes in V2:
>
> - Moved [get|put]_online_mems() inside generic ptdump_walk_pgd()
>
> Changes in V1:
>
> https://lore.kernel.org/all/20250609041214.285664-1-anshuman.khandual@arm.com/
>
> arch/arm64/mm/ptdump_debugfs.c | 3 ---
> arch/riscv/mm/ptdump.c | 3 ---
> arch/s390/mm/dump_pagetables.c | 2 --
> mm/ptdump.c | 2 ++
> 4 files changed, 2 insertions(+), 8 deletions(-)
Acked-by: Alexander Gordeev <agordeev@...ux.ibm.com> # s390
Powered by blists - more mailing lists