[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190521101457.GK32329@dhcp22.suse.cz>
Date: Tue, 21 May 2019 12:14:57 +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, mark.rutland@....com, ira.weiny@...el.com,
david@...hat.com, cai@....pw, logang@...tatee.com,
james.morse@....com, cpandya@...eaurora.org, arunks@...eaurora.org,
dan.j.williams@...el.com, mgorman@...hsingularity.net,
osalvador@...e.de, ard.biesheuvel@....com
Subject: Re: [PATCH V4 3/4] arm64/mm: Hold memory hotplug lock while walking
for kernel page table dump
On Mon 20-05-19 10:48:35, Anshuman Khandual wrote:
> The arm64 page table 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 addresses,
> leading to a number of potential problems.
>
> 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.
I've had a comment on this patch in the previous version which didn't
get answered completely AFAICS. If you really insist then please make
sure to describe why does this really matter because this will make
any further changes to the hotplug locking harder and I would to see
that it is worth the additional trouble.
Thanks!
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists