On Tue, May 14, 2019 at 02:30:05PM +0530, Anshuman Khandual wrote: > The arm64 pagetable dump code can race with concurrent modification of the > kernel page tables. When a leaf entries are modified concurrently, the dump > code may log stale or inconsistent information for a VA range, but this is > otherwise not harmful. > > When intermediate levels of table are freed, the dump code will continue to > use memory which has been freed and potentially reallocated for another > purpose. In such cases, the dump code may dereference bogus addressses, > leading to a number of potential problems. > > Intermediate levels of table may by freed during memory hot-remove, or when > installing a huge mapping in the vmalloc region. To avoid racing with these > cases, take the memory hotplug lock when walking the kernel page table. > > Signed-off-by: Anshuman Khandual <anshuman.khand...@arm.com>
Can we please move this after the next patch (which addresses the huge vmap case), and change the last paragraph to: Intermediate levels of table may by freed during memory hot-remove, which will be enabled by a subsequent patch. To avoid racing with this, take the memory hotplug lock when walking the kernel page table. With that, this looks good to me. Thanks, Mark. > --- > arch/arm64/mm/ptdump_debugfs.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c > index 064163f..80171d1 100644 > --- a/arch/arm64/mm/ptdump_debugfs.c > +++ b/arch/arm64/mm/ptdump_debugfs.c > @@ -7,7 +7,10 @@ > static int ptdump_show(struct seq_file *m, void *v) > { > struct ptdump_info *info = m->private; > + > + get_online_mems(); > ptdump_walk_pgd(m, info); > + put_online_mems(); > return 0; > } > DEFINE_SHOW_ATTRIBUTE(ptdump); > -- > 2.7.4 >