| Message ID | 20200326180730.4754-3-james.morse@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | kexec/memory_hotplug: Prevent removal and accidental use | expand |
On 26.03.20 19:07, James Morse wrote: > Memory added to the system by hotplug has a 'System RAM' resource created > for it. This is exposed to user-space via /proc/iomem. > > This poses problems for kexec on arm64. If kexec decides to place the > kernel in one of these newly onlined regions, the new kernel will find > itself booting from a region not described as memory in the firmware > tables. > > Arm64 doesn't have a structure like the e820 memory map that can be > re-written when memory is brought online. Instead arm64 uses the UEFI > memory map, or the memory node from the DT, sometimes both. We never > rewrite these. > > Allow an architecture to specify a different name for these hotplug > regions. > > Signed-off-by: James Morse <james.morse@arm.com> > --- > mm/memory_hotplug.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index 0a54ffac8c68..69b03dd7fc74 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -42,6 +42,10 @@ > #include "internal.h" > #include "shuffle.h" > > +#ifndef MEMORY_HOTPLUG_RES_NAME > +#define MEMORY_HOTPLUG_RES_NAME "System RAM" > +#endif So I assume changing this for all architectures would result in some user space tool breaking? Are we aware of any? I do wonder if we should simply change it for all architectures if possible. > + > /* > * online_page_callback contains pointer to current page onlining function. > * Initially it is generic_online_page(). If it is required it could be > @@ -103,7 +107,7 @@ static struct resource *register_memory_resource(u64 start, u64 size) > { > struct resource *res; > unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > - char *resource_name = "System RAM"; > + char *resource_name = MEMORY_HOTPLUG_RES_NAME; > > if (start + size > max_mem_size) > return ERR_PTR(-E2BIG); >
Hi David, On 3/27/20 9:59 AM, David Hildenbrand wrote: > On 26.03.20 19:07, James Morse wrote: >> Memory added to the system by hotplug has a 'System RAM' resource created >> for it. This is exposed to user-space via /proc/iomem. >> >> This poses problems for kexec on arm64. If kexec decides to place the >> kernel in one of these newly onlined regions, the new kernel will find >> itself booting from a region not described as memory in the firmware >> tables. >> >> Arm64 doesn't have a structure like the e820 memory map that can be >> re-written when memory is brought online. Instead arm64 uses the UEFI >> memory map, or the memory node from the DT, sometimes both. We never >> rewrite these. >> >> Allow an architecture to specify a different name for these hotplug >> regions. >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >> index 0a54ffac8c68..69b03dd7fc74 100644 >> --- a/mm/memory_hotplug.c >> +++ b/mm/memory_hotplug.c >> @@ -42,6 +42,10 @@ >> #include "internal.h" >> #include "shuffle.h" >> >> +#ifndef MEMORY_HOTPLUG_RES_NAME >> +#define MEMORY_HOTPLUG_RES_NAME "System RAM" >> +#endif > > So I assume changing this for all architectures would result in some > user space tool breaking? Are we aware of any? Last time we had to touch arm64's /proc/iomem strings I went through debian's codesearch for stuff that reads it, kexec-tools was the only thing that parsed it in anger. (From memory, the other tools were looking for PCIe windows to do firmware flashing..) Looking again, having qualifiers on the end of 'System RAM' looks like it could confuse 's390-tools's detect_mem_chunks parser. It looks like the strings that come out of 'FIRMWARE_MEMMAP' are a duplicate set. > I do wonder if we should simply change it for all architectures if possible. If its possible that would be great. But I suspect that ship has sailed, changing it on other architectures could break some fragile parsing code. I'm wary of changing it on arm64, the only thing that makes it tolerable is that memory hot-add was relatively recently merged, and we don't anticipate it being widely used until you can remove memory as well. Changing it on arm64 is to prevent today's versions of kexec-tools from accidentally placing the new kernel in memory that wasn't described at boot. This leads to an unhandled exception during boot[0] because the kernel can't access itself via the mapping of all memory. (hotpluggable regions are only discovered by suitably configured ACPI systems much later) Thanks, James [0] | NUMA: NODE_DATA [mem 0x7fdf1780-0x7fdf3fff] | Unable to handle kernel paging request at virtual address ffff00004230aff8 | Mem abort info: | ESR = 0x96000006 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000006 | CM = 0, WnR = 0 | swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000008181d000 | [ffff00004230aff8] pgd=000000007fff9003, pud=000000007fdf7003, pmd=0000000000000000 | Internal error: Oops: 96000006 [#1] PREEMPT SMP | Modules linked in: | CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-rc3-00098-g3f6c690f5dfe #11618 | Hardware name: linux,dummy-virt (DT) | pstate: 80400085 (Nzcv daIf +PAN -UAO BTYPE=--) | pc : vmemmap_pud_populate+0x2c/0xa0 | lr : vmemmap_populate+0x78/0x154 | Call trace: | vmemmap_pud_populate+0x2c/0xa0 | vmemmap_populate+0x78/0x154 | __populate_section_memmap+0x3c/0x60 | sparse_init_nid+0x29c/0x414 | sparse_init+0x154/0x170 | bootmem_init+0x78/0xdc | setup_arch+0x280/0x5d0 | start_kernel+0x98/0x4f8 | Code: f9469a84 92748e73 8b010e61 cb040033 (f9400261) | random: get_random_bytes called from print_oops_end_marker+0x34/0x60 with crng_init=0 | ---[ end trace 0000000000000000 ]--- | Kernel panic - not syncing: Attempted to kill the idle task! | ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >>> index 0a54ffac8c68..69b03dd7fc74 100644 >>> --- a/mm/memory_hotplug.c >>> +++ b/mm/memory_hotplug.c >>> @@ -42,6 +42,10 @@ >>> #include "internal.h" >>> #include "shuffle.h" >>> >>> +#ifndef MEMORY_HOTPLUG_RES_NAME >>> +#define MEMORY_HOTPLUG_RES_NAME "System RAM" >>> +#endif >> >> So I assume changing this for all architectures would result in some >> user space tool breaking? Are we aware of any? > > Last time we had to touch arm64's /proc/iomem strings I went through debian's > codesearch for stuff that reads it, kexec-tools was the only thing that parsed > it in anger. (From memory, the other tools were looking for PCIe windows to do > firmware flashing..) > > Looking again, having qualifiers on the end of 'System RAM' looks like it could > confuse 's390-tools's detect_mem_chunks parser. Good to know, we should find out if this could work. > > It looks like the strings that come out of 'FIRMWARE_MEMMAP' are a duplicate set. > > >> I do wonder if we should simply change it for all architectures if possible. > > If its possible that would be great. But I suspect that ship has sailed, > changing it on other architectures could break some fragile parsing code. I assume any parser has to be prepared for new types showing up. Otherwise these would not be future proof. The question is if a common prefix is problematic. E.g., Use "Hotplugged System RAM" instead of "System RAM (hotplug)" > > I'm wary of changing it on arm64, the only thing that makes it tolerable is that > memory hot-add was relatively recently merged, and we don't anticipate it being > widely used until you can remove memory as well. > > Changing it on arm64 is to prevent today's versions of kexec-tools from > accidentally placing the new kernel in memory that wasn't described at boot. > This leads to an unhandled exception during boot[0] because the kernel can't > access itself via the mapping of all memory. (hotpluggable regions are only > discovered by suitably configured ACPI systems much later) I want the very same for virtio-mem (initially x86-only, but later open for all archs). Can also be interesting for Hyper-V. kexec should not try to use hotplugged memory as kexec target, as memory blocks can be partially inaccessible. Of course, I can provide an interface to override the name via add_memory(), but having it on all architectures handled in a similar way right from the start would be nicer.
Hi David, On 3/30/20 2:23 PM, David Hildenbrand wrote: >>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >>>> index 0a54ffac8c68..69b03dd7fc74 100644 >>>> --- a/mm/memory_hotplug.c >>>> +++ b/mm/memory_hotplug.c >>>> @@ -42,6 +42,10 @@ >>>> #include "internal.h" >>>> #include "shuffle.h" >>>> >>>> +#ifndef MEMORY_HOTPLUG_RES_NAME >>>> +#define MEMORY_HOTPLUG_RES_NAME "System RAM" >>>> +#endif >>> >>> So I assume changing this for all architectures would result in some >>> user space tool breaking? Are we aware of any? >> >> Last time we had to touch arm64's /proc/iomem strings I went through debian's >> codesearch for stuff that reads it, kexec-tools was the only thing that parsed >> it in anger. (From memory, the other tools were looking for PCIe windows to do >> firmware flashing..) >> >> Looking again, having qualifiers on the end of 'System RAM' looks like it could >> confuse 's390-tools's detect_mem_chunks parser. > > Good to know, we should find out if this could work. > >> >> It looks like the strings that come out of 'FIRMWARE_MEMMAP' are a duplicate set. >> >> >>> I do wonder if we should simply change it for all architectures if possible. >> >> If its possible that would be great. But I suspect that ship has sailed, >> changing it on other architectures could break some fragile parsing code. > > I assume any parser has to be prepared for new types showing up. > Otherwise these would not be future proof. The question is if a common > prefix is problematic. > > E.g., Use "Hotplugged System RAM" instead of "System RAM (hotplug)" Aha, I went for a (suffix) because that is what 32bit Arm did for the boot alias. >> I'm wary of changing it on arm64, the only thing that makes it tolerable is that >> memory hot-add was relatively recently merged, and we don't anticipate it being >> widely used until you can remove memory as well. >> >> Changing it on arm64 is to prevent today's versions of kexec-tools from >> accidentally placing the new kernel in memory that wasn't described at boot. >> This leads to an unhandled exception during boot[0] because the kernel can't >> access itself via the mapping of all memory. (hotpluggable regions are only >> discovered by suitably configured ACPI systems much later) > I want the very same for virtio-mem (initially x86-only, but later open > for all archs). Can also be interesting for Hyper-V. kexec should not > try to use hotplugged memory as kexec target, as memory blocks can be > partially inaccessible. Great! I assumed these placement requirements would be arm64 specific. > Of course, I can provide an interface to override the name via > add_memory(), but having it on all architectures handled in a similar > way right from the start would be nicer. I agree having it the same on all architectures would be good. It sounds like virtio-mem is a better argument for doing this than arm64's firmware memory description. I'll have a read, and maybe post something to linux-arch to do this at rc1. (I assume we'll have a few weeks to make sure arm64 at least uses the same name if it goes on longer) Thanks, James
On 03/26/20 at 06:07pm, James Morse wrote: > Memory added to the system by hotplug has a 'System RAM' resource created > for it. This is exposed to user-space via /proc/iomem. > > This poses problems for kexec on arm64. If kexec decides to place the > kernel in one of these newly onlined regions, the new kernel will find > itself booting from a region not described as memory in the firmware > tables. > > Arm64 doesn't have a structure like the e820 memory map that can be > re-written when memory is brought online. Instead arm64 uses the UEFI > memory map, or the memory node from the DT, sometimes both. We never > rewrite these. Could arm64 use similar way to update DT, or a cooked UEFI maps? Add pingfan in cc, he said ppc64 update the DT after a memremove thus it would be good to just redo a kexec load. Added Pingfan and Hari for comments and corrections. > > Allow an architecture to specify a different name for these hotplug > regions. > > Signed-off-by: James Morse <james.morse@arm.com> > --- > mm/memory_hotplug.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index 0a54ffac8c68..69b03dd7fc74 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -42,6 +42,10 @@ > #include "internal.h" > #include "shuffle.h" > > +#ifndef MEMORY_HOTPLUG_RES_NAME > +#define MEMORY_HOTPLUG_RES_NAME "System RAM" > +#endif > + > /* > * online_page_callback contains pointer to current page onlining function. > * Initially it is generic_online_page(). If it is required it could be > @@ -103,7 +107,7 @@ static struct resource *register_memory_resource(u64 start, u64 size) > { > struct resource *res; > unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > - char *resource_name = "System RAM"; > + char *resource_name = MEMORY_HOTPLUG_RES_NAME; > > if (start + size > max_mem_size) > return ERR_PTR(-E2BIG); > -- > 2.25.1 > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec >
On 04/02/2020 01:49 PM, Dave Young wrote: > On 03/26/20 at 06:07pm, James Morse wrote: >> Memory added to the system by hotplug has a 'System RAM' resource created >> for it. This is exposed to user-space via /proc/iomem. >> >> This poses problems for kexec on arm64. If kexec decides to place the >> kernel in one of these newly onlined regions, the new kernel will find >> itself booting from a region not described as memory in the firmware >> tables. >> >> Arm64 doesn't have a structure like the e820 memory map that can be >> re-written when memory is brought online. Instead arm64 uses the UEFI >> memory map, or the memory node from the DT, sometimes both. We never >> rewrite these. > > Could arm64 use similar way to update DT, or a cooked UEFI maps? > > Add pingfan in cc, he said ppc64 update the DT after a memremove thus it > would be good to just redo a kexec load. > Yes, the memory changes will be observed through device-node under /proc/device-tree/ (which is for powerpc). Later if running kexec -l/-p , it can build new dtb with the latest info from /proc/device-tree > Added Pingfan and Hari for comments and corrections. > >> >> Allow an architecture to specify a different name for these hotplug >> regions. >> >> Signed-off-by: James Morse <james.morse@arm.com> >> --- >> mm/memory_hotplug.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >> index 0a54ffac8c68..69b03dd7fc74 100644 >> --- a/mm/memory_hotplug.c >> +++ b/mm/memory_hotplug.c >> @@ -42,6 +42,10 @@ >> #include "internal.h" >> #include "shuffle.h" >> >> +#ifndef MEMORY_HOTPLUG_RES_NAME >> +#define MEMORY_HOTPLUG_RES_NAME "System RAM" >> +#endif >> + >> /* >> * online_page_callback contains pointer to current page onlining function. >> * Initially it is generic_online_page(). If it is required it could be >> @@ -103,7 +107,7 @@ static struct resource *register_memory_resource(u64 start, u64 size) >> { >> struct resource *res; >> unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; >> - char *resource_name = "System RAM"; >> + char *resource_name = MEMORY_HOTPLUG_RES_NAME; >> >> if (start + size > max_mem_size) >> return ERR_PTR(-E2BIG); >> -- >> 2.25.1 >> >> >> _______________________________________________ >> kexec mailing list >> kexec@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/kexec >>
Hi Dave, Pingfan, On 02/04/2020 07:12, piliu wrote: > On 04/02/2020 01:49 PM, Dave Young wrote: >> On 03/26/20 at 06:07pm, James Morse wrote: >>> Memory added to the system by hotplug has a 'System RAM' resource created >>> for it. This is exposed to user-space via /proc/iomem. >>> >>> This poses problems for kexec on arm64. If kexec decides to place the >>> kernel in one of these newly onlined regions, the new kernel will find >>> itself booting from a region not described as memory in the firmware >>> tables. >>> >>> Arm64 doesn't have a structure like the e820 memory map that can be >>> re-written when memory is brought online. Instead arm64 uses the UEFI >>> memory map, or the memory node from the DT, sometimes both. We never >>> rewrite these. >> >> Could arm64 use similar way to update DT, or a cooked UEFI maps? >> Add pingfan in cc, he said ppc64 update the DT after a memremove thus it >> would be good to just redo a kexec load. > Yes, the memory changes will be observed through device-node under > /proc/device-tree/ (which is for powerpc). > > Later if running kexec -l/-p , it can build new dtb with the latest info > from /proc/device-tree For arm64, the device-tree is set in stone. We don't have the runtime parts of open-firmware that powerpc does. (my knowledge in this area is extremely sparse) arm64 platforms where stuff like this changes tend to use ACPI instead, and these all have to boot with UEFI, which means its the UEFI memory map that has authority. We don't cook a fake UEFI memory map when things change because we treat it like the set-in-stone DT. This means we only have discrepancies in firmware to workaround, instead of any we introduce ourselves. One of the UEFI configuration tables describes addresses Linux programmed into hardware that can't be reset. Newer versions of Linux know how to pick these up on kexec... but older versions don't know how to parse/rewrite/move that table. Cooking up new versions of these tables would prevent us doing stuff like this, which we need to workaround hardware that didn't get the 'kexec exists' memo. Thanks, James
James Morse <james.morse@arm.com> writes: > Memory added to the system by hotplug has a 'System RAM' resource created > for it. This is exposed to user-space via /proc/iomem. > > This poses problems for kexec on arm64. If kexec decides to place the > kernel in one of these newly onlined regions, the new kernel will find > itself booting from a region not described as memory in the firmware > tables. > > Arm64 doesn't have a structure like the e820 memory map that can be > re-written when memory is brought online. Instead arm64 uses the UEFI > memory map, or the memory node from the DT, sometimes both. We never > rewrite these. > > Allow an architecture to specify a different name for these hotplug > regions. Gah. No. Please find a way to pass the current memory map to the loaded kexec'd kernel. Starting a kernel with no way for it to know what the current memory map is just plain scary. Eric
Hi Eric, On 15/04/2020 21:36, Eric W. Biederman wrote: > James Morse <james.morse@arm.com> writes: > >> Memory added to the system by hotplug has a 'System RAM' resource created >> for it. This is exposed to user-space via /proc/iomem. >> >> This poses problems for kexec on arm64. If kexec decides to place the >> kernel in one of these newly onlined regions, the new kernel will find >> itself booting from a region not described as memory in the firmware >> tables. >> >> Arm64 doesn't have a structure like the e820 memory map that can be >> re-written when memory is brought online. Instead arm64 uses the UEFI >> memory map, or the memory node from the DT, sometimes both. We never >> rewrite these. >> >> Allow an architecture to specify a different name for these hotplug >> regions. > > Gah. No. > > Please find a way to pass the current memory map to the loaded kexec'd > kernel. > Starting a kernel with no way for it to know what the current memory map > is just plain scary. We have one. Firmware tables are the source of all this information. We don't tamper with them. Firmware describes memory present at boot in the UEFI memory map or DT. On systems with ACPI, regions that were added after booting are discovered by running AML methods. (for which we need to allocate memory, so you can't describe boot memory like this) This doesn't work if you kexec from a hot-added region. You've booted from memory that wasn't present at boot. I don't think this is fixable with the set of constraints. Thanks, James
On Thu, 26 Mar 2020 18:07:29 +0000 James Morse <james.morse@arm.com> wrote: > Memory added to the system by hotplug has a 'System RAM' resource created > for it. This is exposed to user-space via /proc/iomem. > > This poses problems for kexec on arm64. If kexec decides to place the > kernel in one of these newly onlined regions, the new kernel will find > itself booting from a region not described as memory in the firmware > tables. > > Arm64 doesn't have a structure like the e820 memory map that can be > re-written when memory is brought online. Instead arm64 uses the UEFI > memory map, or the memory node from the DT, sometimes both. We never > rewrite these. > > Allow an architecture to specify a different name for these hotplug > regions. > > ... > > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -42,6 +42,10 @@ > #include "internal.h" > #include "shuffle.h" > > +#ifndef MEMORY_HOTPLUG_RES_NAME > +#define MEMORY_HOTPLUG_RES_NAME "System RAM" > +#endif > + > /* > * online_page_callback contains pointer to current page onlining function. > * Initially it is generic_online_page(). If it is required it could be > @@ -103,7 +107,7 @@ static struct resource *register_memory_resource(u64 start, u64 size) > { > struct resource *res; > unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > - char *resource_name = "System RAM"; > + char *resource_name = MEMORY_HOTPLUG_RES_NAME; > > if (start + size > max_mem_size) > return ERR_PTR(-E2BIG); I suppose we should do this as well: --- a/mm/memory_hotplug.c~mm-memory_hotplug-allow-arch-override-of-non-boot-memory-resource-names-fix +++ a/mm/memory_hotplug.c @@ -129,7 +129,8 @@ static struct resource *register_memory_ resource_name, flags); if (!res) { - pr_debug("Unable to reserve System RAM region: %016llx->%016llx\n", + pr_debug("Unable to reserve " MEMORY_HOTPLUG_RES_NAME + " region: %016llx->%016llx\n", start, start + size); return ERR_PTR(-EEXIST); } It assumes that MEMORY_HOTPLUG_RES_NAME will be a literal string, which is the case in [3/3].
On 09.05.20 02:45, Andrew Morton wrote: > On Thu, 26 Mar 2020 18:07:29 +0000 James Morse <james.morse@arm.com> wrote: > >> Memory added to the system by hotplug has a 'System RAM' resource created >> for it. This is exposed to user-space via /proc/iomem. >> >> This poses problems for kexec on arm64. If kexec decides to place the >> kernel in one of these newly onlined regions, the new kernel will find >> itself booting from a region not described as memory in the firmware >> tables. >> >> Arm64 doesn't have a structure like the e820 memory map that can be >> re-written when memory is brought online. Instead arm64 uses the UEFI >> memory map, or the memory node from the DT, sometimes both. We never >> rewrite these. >> >> Allow an architecture to specify a different name for these hotplug >> regions. >> >> ... >> >> --- a/mm/memory_hotplug.c >> +++ b/mm/memory_hotplug.c >> @@ -42,6 +42,10 @@ >> #include "internal.h" >> #include "shuffle.h" >> >> +#ifndef MEMORY_HOTPLUG_RES_NAME >> +#define MEMORY_HOTPLUG_RES_NAME "System RAM" >> +#endif >> + >> /* >> * online_page_callback contains pointer to current page onlining function. >> * Initially it is generic_online_page(). If it is required it could be >> @@ -103,7 +107,7 @@ static struct resource *register_memory_resource(u64 start, u64 size) >> { >> struct resource *res; >> unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; >> - char *resource_name = "System RAM"; >> + char *resource_name = MEMORY_HOTPLUG_RES_NAME; >> >> if (start + size > max_mem_size) >> return ERR_PTR(-E2BIG); > > I suppose we should do this as well: > > --- a/mm/memory_hotplug.c~mm-memory_hotplug-allow-arch-override-of-non-boot-memory-resource-names-fix > +++ a/mm/memory_hotplug.c > @@ -129,7 +129,8 @@ static struct resource *register_memory_ > resource_name, flags); > > if (!res) { > - pr_debug("Unable to reserve System RAM region: %016llx->%016llx\n", > + pr_debug("Unable to reserve " MEMORY_HOTPLUG_RES_NAME > + " region: %016llx->%016llx\n", > start, start + size); > return ERR_PTR(-EEXIST); > } > > It assumes that MEMORY_HOTPLUG_RES_NAME will be a literal string, which > is the case in [3/3]. @Andrew, as discussed in this thread already [1], I suggest to drop this series from -mm tree for now. [1] https://lkml.kernel.org/r/2e3419b2-d00c-51c3-9b45-9de114608cdf@arm.com
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 0a54ffac8c68..69b03dd7fc74 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -42,6 +42,10 @@ #include "internal.h" #include "shuffle.h" +#ifndef MEMORY_HOTPLUG_RES_NAME +#define MEMORY_HOTPLUG_RES_NAME "System RAM" +#endif + /* * online_page_callback contains pointer to current page onlining function. * Initially it is generic_online_page(). If it is required it could be @@ -103,7 +107,7 @@ static struct resource *register_memory_resource(u64 start, u64 size) { struct resource *res; unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; - char *resource_name = "System RAM"; + char *resource_name = MEMORY_HOTPLUG_RES_NAME; if (start + size > max_mem_size) return ERR_PTR(-E2BIG);
Memory added to the system by hotplug has a 'System RAM' resource created for it. This is exposed to user-space via /proc/iomem. This poses problems for kexec on arm64. If kexec decides to place the kernel in one of these newly onlined regions, the new kernel will find itself booting from a region not described as memory in the firmware tables. Arm64 doesn't have a structure like the e820 memory map that can be re-written when memory is brought online. Instead arm64 uses the UEFI memory map, or the memory node from the DT, sometimes both. We never rewrite these. Allow an architecture to specify a different name for these hotplug regions. Signed-off-by: James Morse <james.morse@arm.com> --- mm/memory_hotplug.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)