LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mark Rutland <firstname.lastname@example.org>
To: Michal Hocko <email@example.com>
Cc: Anshuman Khandual <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
Subject: Re: [PATCH V3 2/4] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump
Date: Thu, 16 May 2019 11:23:54 +0100 [thread overview]
Message-ID: <20190516102354.GB40960@lakrids.cambridge.arm.com> (raw)
On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote:
> 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
It looks like it's not -- I think we're just the first to realise this.
AFAICT x86's debugfs ptdump has the same issue if run conccurently with
memory hot remove. If 32-bit arm supported hot-remove, its ptdump code
would have the same issue.
> 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?
The debugfs part is used intermittently by a few people working on the
arm64 kernel page tables. We use that both to sanity-check that kernel
page tables are created/updated correctly after changes to the arm64 mmu
code, and also to debug issues if/when we encounter issues that appear
to be the result of kernel page table corruption.
So while it's rare to need it, it's really useful to have when we do
need it, and I'd rather not remove it. I'd also rather that it didn't
have latent issues where we can accidentally crash the kernel when using
it, which is what this patch is addressing.
> 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.
I'm not sure if that would help us here; IIUC pfn_to_online_page() alone
doesn't ensure that the page remains online. Is there a way to achieve
that other than get_online_mems()?
The big problem for the ptdump code is when tables are freed, since the
pages can be reused elsewhere (or hot-removed), causing the ptdump code
next prev parent reply other threads:[~2019-05-16 10:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 9:00 [PATCH V3 0/4] arm64/mm: Enable memory hot remove Anshuman Khandual
2019-05-14 9:00 ` [PATCH V3 1/4] mm/hotplug: Reorder arch_remove_memory() call in __remove_memory() Anshuman Khandual
2019-05-14 9:05 ` David Hildenbrand
2019-05-14 9:00 ` [PATCH V3 2/4] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump Anshuman Khandual
2019-05-14 9:16 ` David Hildenbrand
2019-05-14 15:40 ` Mark Rutland
2019-05-15 1:56 ` Anshuman Khandual
2019-05-15 16:58 ` Michal Hocko
2019-05-16 10:23 ` Mark Rutland [this message]
2019-05-16 11:05 ` Michal Hocko
2019-05-22 16:42 ` Mark Rutland
2019-05-24 6:06 ` Anshuman Khandual
2019-05-27 7:20 ` Michal Hocko
2019-05-28 14:09 ` Mark Rutland
2019-05-16 11:06 ` Anshuman Khandual
2019-05-16 11:16 ` Michal Hocko
2019-05-23 8:40 ` David Hildenbrand
2019-05-24 5:43 ` Anshuman Khandual
2019-05-14 9:00 ` [PATCH V3 3/4] arm64/mm: Inhibit huge-vmap with ptdump Anshuman Khandual
2019-05-14 9:20 ` David Hildenbrand
2019-05-16 8:38 ` Ard Biesheuvel
2019-05-14 9:00 ` [PATCH V3 4/4] arm64/mm: Enable memory hot remove Anshuman Khandual
2019-05-14 9:08 ` David Hildenbrand
2019-05-15 11:49 ` Mark Rutland
2019-05-16 5:34 ` Anshuman Khandual
2019-05-16 10:57 ` Mark Rutland
2019-05-17 3:15 ` Anshuman Khandual
2019-05-14 9:10 ` [PATCH V3 0/4] " David Hildenbrand
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH V3 2/4] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).