LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mark Rutland <email@example.com>
To: Michal Hocko <firstname.lastname@example.org>
Cc: Anshuman Khandual <email@example.com>,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [PATCH V3 2/4] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump
Date: Tue, 28 May 2019 15:09:34 +0100 [thread overview]
Message-ID: <20190528140934.GC26178@lakrids.cambridge.arm.com> (raw)
On Mon, May 27, 2019 at 09:20:01AM +0200, Michal Hocko wrote:
> On Wed 22-05-19 17:42:13, Mark Rutland wrote:
> > On Thu, May 16, 2019 at 01:05:29PM +0200, Michal Hocko wrote:
> > > On Thu 16-05-19 11:23:54, Mark Rutland wrote:
> > > > On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote:
> > > > > On Tue 14-05-19 14:30:05, Anshuman Khandual wrote:
> > I don't think that it's reasonable for this code to bring down the
> > kernel unless the kernel page tables are already corrupt. I agree we
> > should minimize the impact on other code, and I'm happy to penalize
> > ptdump so long as it's functional and safe.
> > I would like it to be possible to use the ptdump code to debug
> > hot-remove, so I'd rather not make the two mutually exclusive. I'd also
> > like it to be possible to use this in-the-field, and for that asking an
> > admin to potentially crash their system isn't likely to fly.
> OK, fair enough.
> > > > > 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.
> > Jut to check, is your plan to limit access to the hotplug lock, or to
> > redesign the locking scheme?
> To change the locking to lock hotpluged ranges rather than having a
> global lock as the operation is inherently pfn range scoped.
Ok. That sounds like something we could adapt the ptdump code to handle
without too much pain (modulo how much of that you want to expose
outside of the core mm code).
> > > > 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()?
> > >
> > > You have to pin the page to make sure the hotplug is not going to
> > > offline it.
> > I'm not exactly sure how pinning works -- is there a particular set of
> > functions I should look at for that?
> Pinning (get_page) on any page of the range will deffer the hotremove
> operation and therefore the page tables cannot go away as well.
> That being said, I thought the API is mostly for debugging and "you
> should better know what you are doing" kinda thing (based on debugfs
> being used here). If this is really useful in its current form and
> should be used also while the hotremove is in progress then ok.
> Once we actually get to rework the locking then we will have another
> spot to handle but that's the life.
FWIW, I'm happy to rework the ptdump code to help with that.
next prev parent reply other threads:[~2019-05-28 14:09 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
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 [this message]
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).