[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa03a392-a764-8935-15a9-05cc5ea0230d@redhat.com>
Date: Tue, 14 May 2019 11:16:18 +0200
From: David Hildenbrand <david@...hat.com>
To: Anshuman Khandual <anshuman.khandual@....com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
akpm@...ux-foundation.org, catalin.marinas@....com,
will.deacon@....com
Cc: mhocko@...e.com, mgorman@...hsingularity.net, james.morse@....com,
mark.rutland@....com, robin.murphy@....com, cpandya@...eaurora.org,
arunks@...eaurora.org, dan.j.williams@...el.com, osalvador@...e.de,
cai@....pw, logang@...tatee.com, ira.weiny@...el.com
Subject: Re: [PATCH V3 2/4] arm64/mm: Hold memory hotplug lock while walking
for kernel page table dump
On 14.05.19 11:00, 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.khandual@....com>
> ---
> 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();
The name of that function is somewhat stale now, it used to refer to
online/offlining of pages only. The underlying lock is the
mem_hotplug_lock. Maybe we should rename that function some day ...
> ptdump_walk_pgd(m, info);
> + put_online_mems();
> return 0;
Acked-by: David Hildenbrand <david@...hat.com>
> }
> DEFINE_SHOW_ATTRIBUTE(ptdump);
>
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists