linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org,
	catalin.marinas@arm.com, will@kernel.org
Cc: mark.rutland@arm.com, david@redhat.com, cai@lca.pw,
	logang@deltatee.com, cpandya@codeaurora.org,
	arunks@codeaurora.org, dan.j.williams@intel.com,
	mgorman@techsingularity.net, osalvador@suse.de,
	ard.biesheuvel@arm.com, steve.capper@arm.com, broonie@kernel.org,
	valentin.schneider@arm.com, Robin.Murphy@arm.com,
	steven.price@arm.com, suzuki.poulose@arm.com,
	ira.weiny@intel.com,
	Anshuman Khandual <anshuman.khandual@arm.com>
Subject: [PATCH V11 1/5] mm/hotplug: Introduce arch callback validating the hot remove range
Date: Fri, 10 Jan 2020 08:39:11 +0530	[thread overview]
Message-ID: <1578625755-11792-2-git-send-email-anshuman.khandual@arm.com> (raw)
In-Reply-To: <1578625755-11792-1-git-send-email-anshuman.khandual@arm.com>

Currently there are two interfaces to initiate memory range hot removal i.e
remove_memory() and __remove_memory() which then calls try_remove_memory().
Platform gets called with arch_remove_memory() to tear down required kernel
page tables and other arch specific procedures. But there are platforms
like arm64 which might want to prevent removal of certain specific memory
ranges irrespective of their present usage or movability properties.

Current arch call back arch_remove_memory() is too late in the process to
abort memory hot removal as memory block devices and firmware memory map
entries would have already been removed. Platforms should be able to abort
the process before taking the mem_hotplug_lock with mem_hotplug_begin().
This essentially requires a new arch callback for memory range validation.

This differentiates memory range validation between memory hot add and hot
remove paths before carving out a new helper check_hotremove_memory_range()
which incorporates a new arch callback. This call back provides platforms
an opportunity to refuse memory removal at the very onset. In future the
same principle can be extended for memory hot add path if required.

Platforms can choose to override this callback in order to reject specific
memory ranges from removal or can just fallback to a default implementation
which allows removal of all memory ranges.

Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
 include/linux/memory_hotplug.h |  7 +++++++
 mm/memory_hotplug.c            | 21 ++++++++++++++++++++-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index ba0dca6..f661bd5 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -305,6 +305,13 @@ static inline void pgdat_resize_init(struct pglist_data *pgdat) {}
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
 
+#ifndef arch_memory_removable
+static inline bool arch_memory_removable(u64 base, u64 size)
+{
+	return true;
+}
+#endif
+
 extern bool is_mem_section_removable(unsigned long pfn, unsigned long nr_pages);
 extern void try_offline_node(int nid);
 extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index a91a072..7cdf800 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1014,6 +1014,23 @@ static int check_hotplug_memory_range(u64 start, u64 size)
 	return 0;
 }
 
+static int check_hotremove_memory_range(u64 start, u64 size)
+{
+	int rc;
+
+	BUG_ON(check_hotplug_memory_range(start, size));
+
+	/*
+	 * First check if the platform is willing to have this
+	 * memory range removed else just abort.
+	 */
+	rc = arch_memory_removable(start, size);
+	if (!rc)
+		return -EINVAL;
+
+	return 0;
+}
+
 static int online_memory_block(struct memory_block *mem, void *arg)
 {
 	return device_online(&mem->dev);
@@ -1762,7 +1779,9 @@ static int __ref try_remove_memory(int nid, u64 start, u64 size)
 {
 	int rc = 0;
 
-	BUG_ON(check_hotplug_memory_range(start, size));
+	rc = check_hotremove_memory_range(start, size);
+	if (rc)
+		return rc;
 
 	mem_hotplug_begin();
 
-- 
2.7.4



  reply	other threads:[~2020-01-10  3:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10  3:09 [PATCH V11 0/5] arm64/mm: Enable memory hot remove Anshuman Khandual
2020-01-10  3:09 ` Anshuman Khandual [this message]
2020-01-10  8:42   ` [PATCH V11 1/5] mm/hotplug: Introduce arch callback validating the hot remove range David Hildenbrand
2020-01-13  9:11     ` Anshuman Khandual
2020-01-13  9:14       ` David Hildenbrand
2020-01-13  9:50         ` Anshuman Khandual
2020-01-13 10:37           ` David Hildenbrand
2020-01-14  2:13             ` Anshuman Khandual
2020-01-14 11:09               ` Anshuman Khandual
2020-01-14 12:30                 ` David Hildenbrand
2020-01-11 14:11   ` kbuild test robot
2020-01-13  4:06     ` Anshuman Khandual
2020-01-11 19:49   ` kbuild test robot
2020-01-10  3:09 ` [PATCH V11 2/5] mm/memblock: Introduce MEMBLOCK_BOOT flag Anshuman Khandual
2020-01-13  7:37   ` Mike Rapoport
2020-01-13  8:43     ` Anshuman Khandual
2020-01-13  8:57       ` David Hildenbrand
2020-01-10  3:09 ` [PATCH V11 3/5] of/fdt: Mark boot memory with MEMBLOCK_BOOT Anshuman Khandual
2020-01-10  3:09 ` [PATCH V11 4/5] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump Anshuman Khandual
2020-01-10  3:09 ` [PATCH V11 5/5] arm64/mm: Enable memory hot remove Anshuman Khandual

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1578625755-11792-2-git-send-email-anshuman.khandual@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@arm.com \
    --cc=arunks@codeaurora.org \
    --cc=broonie@kernel.org \
    --cc=cai@lca.pw \
    --cc=catalin.marinas@arm.com \
    --cc=cpandya@codeaurora.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@techsingularity.net \
    --cc=osalvador@suse.de \
    --cc=steve.capper@arm.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=valentin.schneider@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox