Message ID | 20240514140446.538622-6-bjorn@kernel.org (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | riscv: Memory Hot(Un)Plug support | expand |
On 14.05.24 16:04, Björn Töpel wrote: > From: Björn Töpel <bjorn@rivosinc.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@rivosinc.com> > --- > arch/riscv/mm/ptdump.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c > index 1289cc6d3700..9d5f657a251b 100644 > --- a/arch/riscv/mm/ptdump.c > +++ b/arch/riscv/mm/ptdump.c > @@ -6,6 +6,7 @@ > #include <linux/efi.h> > #include <linux/init.h> > #include <linux/debugfs.h> > +#include <linux/memory_hotplug.h> > #include <linux/seq_file.h> > #include <linux/ptdump.h> > > @@ -370,7 +371,9 @@ bool ptdump_check_wx(void) > > static int ptdump_show(struct seq_file *m, void *v) > { > + get_online_mems(); > ptdump_walk(m, m->private); > + put_online_mems(); > > return 0; > } Reviewed-by: David Hildenbrand <david@redhat.com>
On Tue, May 14, 2024 at 04:04:43PM +0200, Björn Töpel wrote: > From: Björn Töpel <bjorn@rivosinc.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@rivosinc.com> Reviewed-by: Oscar Salvador <osalvador@suse.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.
diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c index 1289cc6d3700..9d5f657a251b 100644 --- a/arch/riscv/mm/ptdump.c +++ b/arch/riscv/mm/ptdump.c @@ -6,6 +6,7 @@ #include <linux/efi.h> #include <linux/init.h> #include <linux/debugfs.h> +#include <linux/memory_hotplug.h> #include <linux/seq_file.h> #include <linux/ptdump.h> @@ -370,7 +371,9 @@ bool ptdump_check_wx(void) static int ptdump_show(struct seq_file *m, void *v) { + get_online_mems(); ptdump_walk(m, m->private); + put_online_mems(); return 0; }