From: Catalin Marinas <catalin.marinas@arm•com>
To: Anshuman Khandual <anshuman.khandual@arm•com>
Cc: mark.rutland@arm•com, david@redhat•com, linux-mm@kvack•org,
arunks@codeaurora•org, cpandya@codeaurora•org,
ira.weiny@intel•com, will@kernel•org, steven.price@arm•com,
valentin.schneider@arm•com, suzuki.poulose@arm•com,
Robin.Murphy@arm•com, broonie@kernel•org, cai@lca•pw,
ard.biesheuvel@arm•com, dan.j.williams@intel•com,
linux-arm-kernel@lists•infradead.org, osalvador@suse•de,
steve.capper@arm•com, logang@deltatee•com,
linux-kernel@vger•kernel.org, James Morse <james.morse@arm•com>,
akpm@linux-foundation•org, mgorman@techsingularity•net
Subject: Re: [PATCH V9 2/2] arm64/mm: Enable memory hot remove
Date: Fri, 18 Oct 2019 10:48:25 +0100 [thread overview]
Message-ID: <20191018094825.GD19734@arrakis.emea.arm.com> (raw)
In-Reply-To: <f51cdb20-ddc4-4fb7-6c45-791d2e1e690c@arm.com>
On Fri, Oct 11, 2019 at 08:26:32AM +0530, Anshuman Khandual wrote:
> On 10/10/2019 05:04 PM, Catalin Marinas wrote:
> > Mark Rutland mentioned at some point that, as a preparatory patch to
> > this series, we'd need to make sure we don't hot-remove memory already
> > given to the kernel at boot. Any plans here?
>
> Hmm, this series just enables platform memory hot remove as required from
> generic memory hotplug framework. The path here is triggered either from
> remove_memory() or __remove_memory() which takes physical memory range
> arguments like (nid, start, size) and do the needful. arch_remove_memory()
> should never be required to test given memory range for anything including
> being part of the boot memory.
Assuming arch_remove_memory() doesn't (cannot) check, is there a risk on
arm64 that, for example, one removes memory available at boot and then
kexecs a new kernel? Does the kexec tool present the new kernel with the
original memory map?
I can see x86 has CONFIG_FIRMWARE_MEMMAP suggesting that it is used by
kexec. try_remove_memory() calls firmware_map_remove() so maybe they
solve this problem differently.
Correspondingly, after an arch_add_memory(), do we want a kexec kernel
to access it? x86 seems to use the firmware_map_add_hotplug() mechanism.
Adding James as well for additional comments on kexec scenarios.
> IIUC boot memory added to system with memblock_add() lose all it's identity
> after the system is up and running. In order to reject any attempt to hot
> remove boot memory, platform needs to remember all those memory that came
> early in the boot and then scan through it during arch_remove_memory().
>
> Ideally, it is the responsibility of [_]remove_memory() callers like ACPI
> driver, DAX etc to make sure they never attempt to hot remove a memory
> range, which never got hot added by them in the first place. Also, unlike
> /sys/devices/system/memory/probe there is no 'unprobe' interface where the
> user can just trigger boot memory removal. Hence, unless there is a bug in
> ACPI, DAX or other callers, there should never be any attempt to hot remove
> boot memory in the first place.
That's fine if these callers give such guarantees. I just want to make
sure someone checked all the possible scenarios for memory hot-remove.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-18 9:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-09 8:21 [PATCH V9 0/2] arm64/mm: Enable memory hot remove Anshuman Khandual
2019-10-09 8:21 ` [PATCH V9 1/2] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump Anshuman Khandual
2019-10-09 8:21 ` [PATCH V9 2/2] arm64/mm: Enable memory hot remove Anshuman Khandual
2019-10-10 11:34 ` Catalin Marinas
2019-10-11 2:56 ` Anshuman Khandual
2019-10-18 9:48 ` Catalin Marinas [this message]
2019-10-21 9:53 ` Anshuman Khandual
2019-10-21 9:55 ` Anshuman Khandual
2019-10-25 17:09 ` James Morse
2019-10-28 8:25 ` Anshuman Khandual
2019-11-04 3:57 ` 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=20191018094825.GD19734@arrakis.emea.arm.com \
--to=catalin.marinas@arm$(echo .)com \
--cc=Robin.Murphy@arm$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=anshuman.khandual@arm$(echo .)com \
--cc=ard.biesheuvel@arm$(echo .)com \
--cc=arunks@codeaurora$(echo .)org \
--cc=broonie@kernel$(echo .)org \
--cc=cai@lca$(echo .)pw \
--cc=cpandya@codeaurora$(echo .)org \
--cc=dan.j.williams@intel$(echo .)com \
--cc=david@redhat$(echo .)com \
--cc=ira.weiny@intel$(echo .)com \
--cc=james.morse@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=logang@deltatee$(echo .)com \
--cc=mark.rutland@arm$(echo .)com \
--cc=mgorman@techsingularity$(echo .)net \
--cc=osalvador@suse$(echo .)de \
--cc=steve.capper@arm$(echo .)com \
--cc=steven.price@arm$(echo .)com \
--cc=suzuki.poulose@arm$(echo .)com \
--cc=valentin.schneider@arm$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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