[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZkPRq5zca7PGsqwJ@localhost.localdomain>
Date: Tue, 14 May 2024 23:03:39 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Björn Töpel <bjorn@...nel.org>
Cc: Alexandre Ghiti <alexghiti@...osinc.com>,
Albert Ou <aou@...s.berkeley.edu>,
David Hildenbrand <david@...hat.com>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
linux-riscv@...ts.infradead.org,
Björn Töpel <bjorn@...osinc.com>,
Andrew Bresticker <abrestic@...osinc.com>,
Chethan Seshadri <Chethan.Seshadri@...alinasystems.io>,
Lorenzo Stoakes <lstoakes@...il.com>,
Santosh Mamila <santosh.mamila@...alinasystems.io>,
Sivakumar Munnangi <siva.munnangi@...alinasystems.io>,
Sunil V L <sunilvl@...tanamicro.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v2 5/8] riscv: mm: Take memory hotplug read-lock during
kernel page table dump
On Tue, May 14, 2024 at 04:04:43PM +0200, Björn Töpel wrote:
> From: Björn Töpel <bjorn@...osinc.com>
>
> During memory hot remove, the ptdump functionality can end up touching
> stale data. Avoid any potential crashes (or worse), by holding the
> memory hotplug read-lock while traversing the page table.
>
> This change is analogous to arm64's commit bf2b59f60ee1 ("arm64/mm:
> Hold memory hotplug lock while walking for kernel page table dump").
>
> Signed-off-by: Björn Töpel <bjorn@...osinc.com>
Reviewed-by: Oscar Salvador <osalvador@...e.de>
funny enough, it seems arm64 and riscv are the only ones holding the
hotplug lock here.
I think we have the same problem on the other arches as well (at least
on x86_64 that I can see).
If we happen to finally need the lock in those, I would rather have a
centric function in the generic mm code with the locking and then
calling an arch specific ptdump_show function, so the lock is not
scattered. But that is another story.
--
Oscar Salvador
SUSE Labs
Powered by blists - more mailing lists