[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190515165847.GH16651@dhcp22.suse.cz>
Date: Wed, 15 May 2019 18:58:47 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
akpm@...ux-foundation.org, catalin.marinas@....com,
will.deacon@....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, david@...hat.com,
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 Tue 14-05-19 14:30:05, 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.
Why is this a problem only on arm64 and why do we even care for debugfs?
Does anybody rely on this thing to be reliable? Do we even need it? Who
is using the file?
I am asking because I would really love to make mem hotplug locking less
scattered outside of the core MM than more. Most users simply shouldn't
care. Pfn walkers should rely on pfn_to_online_page.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists