License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2006-12-08 14:56:07 +00:00
|
|
|
/*
|
|
|
|
* Copyright IBM Corp. 2006
|
|
|
|
*/
|
|
|
|
|
2021-02-26 01:17:41 +00:00
|
|
|
#include <linux/memory_hotplug.h>
|
2025-02-07 14:48:53 +00:00
|
|
|
#include <linux/cpufeature.h>
|
2018-10-30 22:09:49 +00:00
|
|
|
#include <linux/memblock.h>
|
2006-12-08 14:56:07 +00:00
|
|
|
#include <linux/pfn.h>
|
|
|
|
#include <linux/mm.h>
|
2017-02-09 20:20:24 +00:00
|
|
|
#include <linux/init.h>
|
2006-12-08 14:56:07 +00:00
|
|
|
#include <linux/list.h>
|
2008-04-30 11:38:46 +00:00
|
|
|
#include <linux/hugetlb.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2022-12-13 10:35:11 +00:00
|
|
|
#include <linux/sort.h>
|
2023-10-17 19:07:04 +00:00
|
|
|
#include <asm/page-states.h>
|
2024-03-01 06:05:39 +00:00
|
|
|
#include <asm/abs_lowcore.h>
|
2016-05-10 14:28:28 +00:00
|
|
|
#include <asm/cacheflush.h>
|
s390/mm: Uncouple physical vs virtual address spaces
The uncoupling physical vs virtual address spaces brings
the following benefits to s390:
- virtual memory layout flexibility;
- closes the address gap between kernel and modules, it
caused s390-only problems in the past (e.g. 'perf' bugs);
- allows getting rid of trampolines used for module calls
into kernel;
- allows simplifying BPF trampoline;
- minor performance improvement in branch prediction;
- kernel randomization entropy is magnitude bigger, as it is
derived from the amount of available virtual, not physical
memory;
The whole change could be described in two pictures below:
before and after the change.
Some aspects of the virtual memory layout setup are not
clarified (number of page levels, alignment, DMA memory),
since these are not a part of this change or secondary
with regard to how the uncoupling itself is implemented.
The focus of the pictures is to explain why __va() and __pa()
macros are implemented the way they are.
Memory layout in V==R mode:
| Physical | Virtual |
+- 0 --------------+- 0 --------------+ identity mapping start
| | S390_lowcore | Low-address memory
| +- 8 KB -----------+
| | |
| | identity | phys == virt
| | mapping | virt == phys
| | |
+- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start
|.amode31 text/data|.amode31 text/data|
+- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt start
| | |
| | |
+- __kaslr_offset, __kaslr_offset_phys| kernel rand. phys/virt start
| | |
| kernel text/data | kernel text/data | phys == kvirt
| | |
+------------------+------------------+ kernel phys/virt end
| | |
| | |
| | |
| | |
+- ident_map_size -+- ident_map_size -+ identity mapping end
| |
| ... unused gap |
| |
+---- vmemmap -----+ 'struct page' array start
| |
| virtually mapped |
| memory map |
| |
+- __abs_lowcore --+
| |
| Absolute Lowcore |
| |
+- __memcpy_real_area
| |
| Real Memory Copy|
| |
+- VMALLOC_START --+ vmalloc area start
| |
| vmalloc area |
| |
+- MODULES_VADDR --+ modules area start
| |
| modules area |
| |
+------------------+ UltraVisor Secure Storage limit
| |
| ... unused gap |
| |
+KASAN_SHADOW_START+ KASAN shadow memory start
| |
| KASAN shadow |
| |
+------------------+ ASCE limit
Memory layout in V!=R mode:
| Physical | Virtual |
+- 0 --------------+- 0 --------------+
| | S390_lowcore | Low-address memory
| +- 8 KB -----------+
| | |
| | |
| | ... unused gap |
| | |
+- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start
|.amode31 text/data|.amode31 text/data|
+- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt end (<2GB)
| | |
| | |
+- __kaslr_offset_phys | kernel rand. phys start
| | |
| kernel text/data | |
| | |
+------------------+ | kernel phys end
| | |
| | |
| | |
| | |
+- ident_map_size -+ |
| |
| ... unused gap |
| |
+- __identity_base + identity mapping start (>= 2GB)
| |
| identity | phys == virt - __identity_base
| mapping | virt == phys + __identity_base
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+---- vmemmap -----+ 'struct page' array start
| |
| virtually mapped |
| memory map |
| |
+- __abs_lowcore --+
| |
| Absolute Lowcore |
| |
+- __memcpy_real_area
| |
| Real Memory Copy|
| |
+- VMALLOC_START --+ vmalloc area start
| |
| vmalloc area |
| |
+- MODULES_VADDR --+ modules area start
| |
| modules area |
| |
+- __kaslr_offset -+ kernel rand. virt start
| |
| kernel text/data | phys == (kvirt - __kaslr_offset) +
| | __kaslr_offset_phys
+- kernel .bss end + kernel rand. virt end
| |
| ... unused gap |
| |
+------------------+ UltraVisor Secure Storage limit
| |
| ... unused gap |
| |
+KASAN_SHADOW_START+ KASAN shadow memory start
| |
| KASAN shadow |
| |
+------------------+ ASCE limit
Unused gaps in the virtual memory layout could be present
or not - depending on how partucular system is configured.
No page tables are created for the unused gaps.
The relative order of vmalloc, modules and kernel image in
virtual memory is defined by following considerations:
- start of the modules area and end of the kernel should reside
within 4GB to accommodate relative 32-bit jumps. The best way
to achieve that is to place kernel next to modules;
- vmalloc and module areas should locate next to each other
to prevent failures and extra reworks in user level tools
(makedumpfile, crash, etc.) which treat vmalloc and module
addresses similarily;
- kernel needs to be the last area in the virtual memory
layout to easily distinguish between kernel and non-kernel
virtual addresses. That is needed to (again) simplify
handling of addresses in user level tools and make __pa()
macro faster (see below);
Concluding the above, the relative order of the considered
virtual areas in memory is: vmalloc - modules - kernel.
Therefore, the only change to the current memory layout is
moving kernel to the end of virtual address space.
With that approach the implementation of __pa() macro is
straightforward - all linear virtual addresses less than
kernel base are considered identity mapping:
phys == virt - __identity_base
All addresses greater than kernel base are kernel ones:
phys == (kvirt - __kaslr_offset) + __kaslr_offset_phys
By contrast, __va() macro deals only with identity mapping
addresses:
virt == phys + __identity_base
.amode31 section is mapped separately and is not covered by
__pa() macro. In fact, it could have been handled easily by
checking whether a virtual address is within the section or
not, but there is no need for that. Thus, let __pa() code
do as little machine cycles as possible.
The KASAN shadow memory is located at the very end of the
virtual memory layout, at addresses higher than the kernel.
However, that is not a linear mapping and no code other than
KASAN instrumentation or API is expected to access it.
When KASLR mode is enabled the kernel base address randomized
within a memory window that spans whole unused virtual address
space. The size of that window depends from the amount of
physical memory available to the system, the limit imposed by
UltraVisor (if present) and the vmalloc area size as provided
by vmalloc= kernel command line parameter.
In case the virtual memory is exhausted the minimum size of
the randomization window is forcefully set to 2GB, which
amounts to in 15 bits of entropy if KASAN is enabled or 17
bits of entropy in default configuration.
The default kernel offset 0x100000 is used as a magic value
both in the decompressor code and vmlinux linker script, but
it will be removed with a follow-up change.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2024-03-01 06:15:22 +00:00
|
|
|
#include <asm/maccess.h>
|
2021-04-07 07:20:17 +00:00
|
|
|
#include <asm/nospec-branch.h>
|
2023-09-11 19:39:56 +00:00
|
|
|
#include <asm/ctlreg.h>
|
2006-12-08 14:56:07 +00:00
|
|
|
#include <asm/pgalloc.h>
|
|
|
|
#include <asm/setup.h>
|
|
|
|
#include <asm/tlbflush.h>
|
2008-04-30 11:38:46 +00:00
|
|
|
#include <asm/sections.h>
|
2017-05-08 22:58:08 +00:00
|
|
|
#include <asm/set_memory.h>
|
s390/mm: Uncouple physical vs virtual address spaces
The uncoupling physical vs virtual address spaces brings
the following benefits to s390:
- virtual memory layout flexibility;
- closes the address gap between kernel and modules, it
caused s390-only problems in the past (e.g. 'perf' bugs);
- allows getting rid of trampolines used for module calls
into kernel;
- allows simplifying BPF trampoline;
- minor performance improvement in branch prediction;
- kernel randomization entropy is magnitude bigger, as it is
derived from the amount of available virtual, not physical
memory;
The whole change could be described in two pictures below:
before and after the change.
Some aspects of the virtual memory layout setup are not
clarified (number of page levels, alignment, DMA memory),
since these are not a part of this change or secondary
with regard to how the uncoupling itself is implemented.
The focus of the pictures is to explain why __va() and __pa()
macros are implemented the way they are.
Memory layout in V==R mode:
| Physical | Virtual |
+- 0 --------------+- 0 --------------+ identity mapping start
| | S390_lowcore | Low-address memory
| +- 8 KB -----------+
| | |
| | identity | phys == virt
| | mapping | virt == phys
| | |
+- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start
|.amode31 text/data|.amode31 text/data|
+- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt start
| | |
| | |
+- __kaslr_offset, __kaslr_offset_phys| kernel rand. phys/virt start
| | |
| kernel text/data | kernel text/data | phys == kvirt
| | |
+------------------+------------------+ kernel phys/virt end
| | |
| | |
| | |
| | |
+- ident_map_size -+- ident_map_size -+ identity mapping end
| |
| ... unused gap |
| |
+---- vmemmap -----+ 'struct page' array start
| |
| virtually mapped |
| memory map |
| |
+- __abs_lowcore --+
| |
| Absolute Lowcore |
| |
+- __memcpy_real_area
| |
| Real Memory Copy|
| |
+- VMALLOC_START --+ vmalloc area start
| |
| vmalloc area |
| |
+- MODULES_VADDR --+ modules area start
| |
| modules area |
| |
+------------------+ UltraVisor Secure Storage limit
| |
| ... unused gap |
| |
+KASAN_SHADOW_START+ KASAN shadow memory start
| |
| KASAN shadow |
| |
+------------------+ ASCE limit
Memory layout in V!=R mode:
| Physical | Virtual |
+- 0 --------------+- 0 --------------+
| | S390_lowcore | Low-address memory
| +- 8 KB -----------+
| | |
| | |
| | ... unused gap |
| | |
+- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start
|.amode31 text/data|.amode31 text/data|
+- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt end (<2GB)
| | |
| | |
+- __kaslr_offset_phys | kernel rand. phys start
| | |
| kernel text/data | |
| | |
+------------------+ | kernel phys end
| | |
| | |
| | |
| | |
+- ident_map_size -+ |
| |
| ... unused gap |
| |
+- __identity_base + identity mapping start (>= 2GB)
| |
| identity | phys == virt - __identity_base
| mapping | virt == phys + __identity_base
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+---- vmemmap -----+ 'struct page' array start
| |
| virtually mapped |
| memory map |
| |
+- __abs_lowcore --+
| |
| Absolute Lowcore |
| |
+- __memcpy_real_area
| |
| Real Memory Copy|
| |
+- VMALLOC_START --+ vmalloc area start
| |
| vmalloc area |
| |
+- MODULES_VADDR --+ modules area start
| |
| modules area |
| |
+- __kaslr_offset -+ kernel rand. virt start
| |
| kernel text/data | phys == (kvirt - __kaslr_offset) +
| | __kaslr_offset_phys
+- kernel .bss end + kernel rand. virt end
| |
| ... unused gap |
| |
+------------------+ UltraVisor Secure Storage limit
| |
| ... unused gap |
| |
+KASAN_SHADOW_START+ KASAN shadow memory start
| |
| KASAN shadow |
| |
+------------------+ ASCE limit
Unused gaps in the virtual memory layout could be present
or not - depending on how partucular system is configured.
No page tables are created for the unused gaps.
The relative order of vmalloc, modules and kernel image in
virtual memory is defined by following considerations:
- start of the modules area and end of the kernel should reside
within 4GB to accommodate relative 32-bit jumps. The best way
to achieve that is to place kernel next to modules;
- vmalloc and module areas should locate next to each other
to prevent failures and extra reworks in user level tools
(makedumpfile, crash, etc.) which treat vmalloc and module
addresses similarily;
- kernel needs to be the last area in the virtual memory
layout to easily distinguish between kernel and non-kernel
virtual addresses. That is needed to (again) simplify
handling of addresses in user level tools and make __pa()
macro faster (see below);
Concluding the above, the relative order of the considered
virtual areas in memory is: vmalloc - modules - kernel.
Therefore, the only change to the current memory layout is
moving kernel to the end of virtual address space.
With that approach the implementation of __pa() macro is
straightforward - all linear virtual addresses less than
kernel base are considered identity mapping:
phys == virt - __identity_base
All addresses greater than kernel base are kernel ones:
phys == (kvirt - __kaslr_offset) + __kaslr_offset_phys
By contrast, __va() macro deals only with identity mapping
addresses:
virt == phys + __identity_base
.amode31 section is mapped separately and is not covered by
__pa() macro. In fact, it could have been handled easily by
checking whether a virtual address is within the section or
not, but there is no need for that. Thus, let __pa() code
do as little machine cycles as possible.
The KASAN shadow memory is located at the very end of the
virtual memory layout, at addresses higher than the kernel.
However, that is not a linear mapping and no code other than
KASAN instrumentation or API is expected to access it.
When KASLR mode is enabled the kernel base address randomized
within a memory window that spans whole unused virtual address
space. The size of that window depends from the amount of
physical memory available to the system, the limit imposed by
UltraVisor (if present) and the vmalloc area size as provided
by vmalloc= kernel command line parameter.
In case the virtual memory is exhausted the minimum size of
the randomization window is forcefully set to 2GB, which
amounts to in 15 bits of entropy if KASAN is enabled or 17
bits of entropy in default configuration.
The default kernel offset 0x100000 is used as a magic value
both in the decompressor code and vmlinux linker script, but
it will be removed with a follow-up change.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2024-03-01 06:15:22 +00:00
|
|
|
#include <asm/physmem_info.h>
|
2006-12-08 14:56:07 +00:00
|
|
|
|
|
|
|
static DEFINE_MUTEX(vmem_mutex);
|
|
|
|
|
2008-05-30 08:03:27 +00:00
|
|
|
static void __ref *vmem_alloc_pages(unsigned int order)
|
|
|
|
{
|
2016-05-13 09:10:09 +00:00
|
|
|
unsigned long size = PAGE_SIZE << order;
|
|
|
|
|
2008-05-30 08:03:27 +00:00
|
|
|
if (slab_is_available())
|
|
|
|
return (void *)__get_free_pages(GFP_KERNEL, order);
|
2021-02-12 06:43:19 +00:00
|
|
|
return memblock_alloc(size, size);
|
2008-05-30 08:03:27 +00:00
|
|
|
}
|
|
|
|
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
static void vmem_free_pages(unsigned long addr, int order, struct vmem_altmap *altmap)
|
2020-07-22 09:45:52 +00:00
|
|
|
{
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
if (altmap) {
|
|
|
|
vmem_altmap_free(altmap, 1 << order);
|
|
|
|
return;
|
|
|
|
}
|
2020-07-22 09:45:52 +00:00
|
|
|
/* We don't expect boot memory to be removed ever. */
|
|
|
|
if (!slab_is_available() ||
|
2023-08-12 15:12:54 +00:00
|
|
|
WARN_ON_ONCE(PageReserved(virt_to_page((void *)addr))))
|
2020-07-22 09:45:52 +00:00
|
|
|
return;
|
|
|
|
free_pages(addr, order);
|
|
|
|
}
|
|
|
|
|
2017-06-16 15:51:15 +00:00
|
|
|
void *vmem_crst_alloc(unsigned long val)
|
2017-04-24 16:19:10 +00:00
|
|
|
{
|
2017-06-16 15:51:15 +00:00
|
|
|
unsigned long *table;
|
2017-04-24 16:19:10 +00:00
|
|
|
|
2017-06-16 15:51:15 +00:00
|
|
|
table = vmem_alloc_pages(CRST_ALLOC_ORDER);
|
2023-10-17 19:07:04 +00:00
|
|
|
if (!table)
|
|
|
|
return NULL;
|
|
|
|
crst_table_init(table, val);
|
2023-10-27 12:12:39 +00:00
|
|
|
__arch_set_page_dat(table, 1UL << CRST_ALLOC_ORDER);
|
2017-06-16 15:51:15 +00:00
|
|
|
return table;
|
2006-12-08 14:56:07 +00:00
|
|
|
}
|
|
|
|
|
2016-05-17 08:50:15 +00:00
|
|
|
pte_t __ref *vmem_pte_alloc(void)
|
2006-12-08 14:56:07 +00:00
|
|
|
{
|
2016-10-18 11:35:32 +00:00
|
|
|
unsigned long size = PTRS_PER_PTE * sizeof(pte_t);
|
2008-02-09 17:24:35 +00:00
|
|
|
pte_t *pte;
|
2006-12-08 14:56:07 +00:00
|
|
|
|
2008-02-09 17:24:35 +00:00
|
|
|
if (slab_is_available())
|
2014-04-30 14:04:25 +00:00
|
|
|
pte = (pte_t *) page_table_alloc(&init_mm);
|
2008-02-09 17:24:35 +00:00
|
|
|
else
|
2021-02-12 06:43:19 +00:00
|
|
|
pte = (pte_t *) memblock_alloc(size, size);
|
2006-12-08 14:56:07 +00:00
|
|
|
if (!pte)
|
|
|
|
return NULL;
|
2017-10-04 17:27:07 +00:00
|
|
|
memset64((u64 *)pte, _PAGE_INVALID, PTRS_PER_PTE);
|
2023-10-27 12:12:39 +00:00
|
|
|
__arch_set_page_dat(pte, 1);
|
2006-12-08 14:56:07 +00:00
|
|
|
return pte;
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:55 +00:00
|
|
|
static void vmem_pte_free(unsigned long *table)
|
|
|
|
{
|
|
|
|
/* We don't expect boot memory to be removed ever. */
|
|
|
|
if (!slab_is_available() ||
|
|
|
|
WARN_ON_ONCE(PageReserved(virt_to_page(table))))
|
|
|
|
return;
|
|
|
|
page_table_free(&init_mm, table);
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:57 +00:00
|
|
|
#define PAGE_UNUSED 0xFD
|
|
|
|
|
2020-07-22 09:45:58 +00:00
|
|
|
/*
|
|
|
|
* The unused vmemmap range, which was not yet memset(PAGE_UNUSED) ranges
|
2020-11-10 09:36:23 +00:00
|
|
|
* from unused_sub_pmd_start to next PMD_SIZE boundary.
|
2020-07-22 09:45:58 +00:00
|
|
|
*/
|
2020-11-10 09:36:23 +00:00
|
|
|
static unsigned long unused_sub_pmd_start;
|
2020-07-22 09:45:58 +00:00
|
|
|
|
2020-11-10 09:36:23 +00:00
|
|
|
static void vmemmap_flush_unused_sub_pmd(void)
|
2020-07-22 09:45:58 +00:00
|
|
|
{
|
2020-11-10 09:36:23 +00:00
|
|
|
if (!unused_sub_pmd_start)
|
2020-07-22 09:45:58 +00:00
|
|
|
return;
|
2021-02-12 06:43:19 +00:00
|
|
|
memset((void *)unused_sub_pmd_start, PAGE_UNUSED,
|
2020-11-10 09:36:23 +00:00
|
|
|
ALIGN(unused_sub_pmd_start, PMD_SIZE) - unused_sub_pmd_start);
|
|
|
|
unused_sub_pmd_start = 0;
|
2020-07-22 09:45:58 +00:00
|
|
|
}
|
|
|
|
|
2020-11-10 09:36:23 +00:00
|
|
|
static void vmemmap_mark_sub_pmd_used(unsigned long start, unsigned long end)
|
2020-07-22 09:45:57 +00:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* As we expect to add in the same granularity as we remove, it's
|
|
|
|
* sufficient to mark only some piece used to block the memmap page from
|
|
|
|
* getting removed (just in case the memmap never gets initialized,
|
|
|
|
* e.g., because the memory block never gets onlined).
|
|
|
|
*/
|
2021-02-12 06:43:19 +00:00
|
|
|
memset((void *)start, 0, sizeof(struct page));
|
2020-07-22 09:45:57 +00:00
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:58 +00:00
|
|
|
static void vmemmap_use_sub_pmd(unsigned long start, unsigned long end)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We only optimize if the new used range directly follows the
|
|
|
|
* previously unused range (esp., when populating consecutive sections).
|
|
|
|
*/
|
2020-11-10 09:36:23 +00:00
|
|
|
if (unused_sub_pmd_start == start) {
|
|
|
|
unused_sub_pmd_start = end;
|
|
|
|
if (likely(IS_ALIGNED(unused_sub_pmd_start, PMD_SIZE)))
|
|
|
|
unused_sub_pmd_start = 0;
|
2020-07-22 09:45:58 +00:00
|
|
|
return;
|
|
|
|
}
|
2020-11-10 09:36:23 +00:00
|
|
|
vmemmap_flush_unused_sub_pmd();
|
|
|
|
vmemmap_mark_sub_pmd_used(start, end);
|
2020-07-22 09:45:58 +00:00
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:57 +00:00
|
|
|
static void vmemmap_use_new_sub_pmd(unsigned long start, unsigned long end)
|
|
|
|
{
|
2021-02-12 06:43:19 +00:00
|
|
|
unsigned long page = ALIGN_DOWN(start, PMD_SIZE);
|
2020-07-22 09:45:57 +00:00
|
|
|
|
2020-11-10 09:36:23 +00:00
|
|
|
vmemmap_flush_unused_sub_pmd();
|
2020-07-22 09:45:58 +00:00
|
|
|
|
2020-07-22 09:45:57 +00:00
|
|
|
/* Could be our memmap page is filled with PAGE_UNUSED already ... */
|
2020-11-10 09:36:23 +00:00
|
|
|
vmemmap_mark_sub_pmd_used(start, end);
|
2020-07-22 09:45:57 +00:00
|
|
|
|
|
|
|
/* Mark the unused parts of the new memmap page PAGE_UNUSED. */
|
|
|
|
if (!IS_ALIGNED(start, PMD_SIZE))
|
2021-02-12 06:43:19 +00:00
|
|
|
memset((void *)page, PAGE_UNUSED, start - page);
|
2020-07-22 09:45:58 +00:00
|
|
|
/*
|
|
|
|
* We want to avoid memset(PAGE_UNUSED) when populating the vmemmap of
|
|
|
|
* consecutive sections. Remember for the last added PMD the last
|
|
|
|
* unused range in the populated PMD.
|
|
|
|
*/
|
2020-07-22 09:45:57 +00:00
|
|
|
if (!IS_ALIGNED(end, PMD_SIZE))
|
2020-11-10 09:36:23 +00:00
|
|
|
unused_sub_pmd_start = end;
|
2020-07-22 09:45:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Returns true if the PMD is completely unused and can be freed. */
|
|
|
|
static bool vmemmap_unuse_sub_pmd(unsigned long start, unsigned long end)
|
|
|
|
{
|
2021-02-12 06:43:19 +00:00
|
|
|
unsigned long page = ALIGN_DOWN(start, PMD_SIZE);
|
2020-07-22 09:45:57 +00:00
|
|
|
|
2020-11-10 09:36:23 +00:00
|
|
|
vmemmap_flush_unused_sub_pmd();
|
2021-02-12 06:43:19 +00:00
|
|
|
memset((void *)start, PAGE_UNUSED, end - start);
|
|
|
|
return !memchr_inv((void *)page, PAGE_UNUSED, PMD_SIZE);
|
2020-07-22 09:45:57 +00:00
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:52 +00:00
|
|
|
/* __ref: we'll only call vmemmap_alloc_block() via vmemmap_populate() */
|
|
|
|
static int __ref modify_pte_table(pmd_t *pmd, unsigned long addr,
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
unsigned long end, bool add, bool direct,
|
|
|
|
struct vmem_altmap *altmap)
|
2006-12-08 14:56:07 +00:00
|
|
|
{
|
2020-07-22 09:45:51 +00:00
|
|
|
unsigned long prot, pages = 0;
|
2020-07-22 09:45:52 +00:00
|
|
|
int ret = -ENOMEM;
|
2020-07-22 09:45:51 +00:00
|
|
|
pte_t *pte;
|
2006-12-08 14:56:07 +00:00
|
|
|
|
2020-07-22 09:45:51 +00:00
|
|
|
prot = pgprot_val(PAGE_KERNEL);
|
|
|
|
pte = pte_offset_kernel(pmd, addr);
|
|
|
|
for (; addr < end; addr += PAGE_SIZE, pte++) {
|
|
|
|
if (!add) {
|
|
|
|
if (pte_none(*pte))
|
|
|
|
continue;
|
2020-07-22 09:45:52 +00:00
|
|
|
if (!direct)
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
vmem_free_pages((unsigned long)pfn_to_virt(pte_pfn(*pte)), get_order(PAGE_SIZE), altmap);
|
2020-07-22 09:45:51 +00:00
|
|
|
pte_clear(&init_mm, addr, pte);
|
|
|
|
} else if (pte_none(*pte)) {
|
2020-07-22 09:45:52 +00:00
|
|
|
if (!direct) {
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
void *new_page = vmemmap_alloc_block_buf(PAGE_SIZE, NUMA_NO_NODE, altmap);
|
2020-07-22 09:45:52 +00:00
|
|
|
|
|
|
|
if (!new_page)
|
|
|
|
goto out;
|
2022-02-21 19:50:07 +00:00
|
|
|
set_pte(pte, __pte(__pa(new_page) | prot));
|
2020-07-23 19:42:36 +00:00
|
|
|
} else {
|
2022-02-21 19:50:07 +00:00
|
|
|
set_pte(pte, __pte(__pa(addr) | prot));
|
2020-07-23 19:42:36 +00:00
|
|
|
}
|
|
|
|
} else {
|
2020-07-22 09:45:51 +00:00
|
|
|
continue;
|
2020-07-23 19:42:36 +00:00
|
|
|
}
|
2020-07-22 09:45:51 +00:00
|
|
|
pages++;
|
2016-03-22 09:54:24 +00:00
|
|
|
}
|
2020-07-22 09:45:52 +00:00
|
|
|
ret = 0;
|
|
|
|
out:
|
|
|
|
if (direct)
|
|
|
|
update_page_count(PG_DIRECT_MAP_4K, add ? pages : -pages);
|
|
|
|
return ret;
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:55 +00:00
|
|
|
static void try_free_pte_table(pmd_t *pmd, unsigned long start)
|
|
|
|
{
|
|
|
|
pte_t *pte;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* We can safely assume this is fully in 1:1 mapping & vmemmap area */
|
|
|
|
pte = pte_offset_kernel(pmd, start);
|
2020-07-23 19:42:36 +00:00
|
|
|
for (i = 0; i < PTRS_PER_PTE; i++, pte++) {
|
2020-07-22 09:45:55 +00:00
|
|
|
if (!pte_none(*pte))
|
|
|
|
return;
|
2020-07-23 19:42:36 +00:00
|
|
|
}
|
2021-02-12 06:43:19 +00:00
|
|
|
vmem_pte_free((unsigned long *) pmd_deref(*pmd));
|
2020-07-22 09:45:55 +00:00
|
|
|
pmd_clear(pmd);
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:52 +00:00
|
|
|
/* __ref: we'll only call vmemmap_alloc_block() via vmemmap_populate() */
|
|
|
|
static int __ref modify_pmd_table(pud_t *pud, unsigned long addr,
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
unsigned long end, bool add, bool direct,
|
|
|
|
struct vmem_altmap *altmap)
|
2020-07-22 09:45:51 +00:00
|
|
|
{
|
|
|
|
unsigned long next, prot, pages = 0;
|
|
|
|
int ret = -ENOMEM;
|
|
|
|
pmd_t *pmd;
|
|
|
|
pte_t *pte;
|
|
|
|
|
|
|
|
prot = pgprot_val(SEGMENT_KERNEL);
|
|
|
|
pmd = pmd_offset(pud, addr);
|
|
|
|
for (; addr < end; addr = next, pmd++) {
|
|
|
|
next = pmd_addr_end(addr, end);
|
|
|
|
if (!add) {
|
|
|
|
if (pmd_none(*pmd))
|
|
|
|
continue;
|
2024-03-05 04:37:47 +00:00
|
|
|
if (pmd_leaf(*pmd)) {
|
2020-07-22 09:45:51 +00:00
|
|
|
if (IS_ALIGNED(addr, PMD_SIZE) &&
|
|
|
|
IS_ALIGNED(next, PMD_SIZE)) {
|
2020-07-22 09:45:52 +00:00
|
|
|
if (!direct)
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
vmem_free_pages(pmd_deref(*pmd), get_order(PMD_SIZE), altmap);
|
2020-07-22 09:45:51 +00:00
|
|
|
pmd_clear(pmd);
|
|
|
|
pages++;
|
2020-07-23 19:42:36 +00:00
|
|
|
} else if (!direct && vmemmap_unuse_sub_pmd(addr, next)) {
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
vmem_free_pages(pmd_deref(*pmd), get_order(PMD_SIZE), altmap);
|
2020-07-22 09:45:57 +00:00
|
|
|
pmd_clear(pmd);
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
} else if (pmd_none(*pmd)) {
|
|
|
|
if (IS_ALIGNED(addr, PMD_SIZE) &&
|
|
|
|
IS_ALIGNED(next, PMD_SIZE) &&
|
2025-02-07 14:48:53 +00:00
|
|
|
cpu_has_edat1() && direct &&
|
2020-07-22 09:45:51 +00:00
|
|
|
!debug_pagealloc_enabled()) {
|
2022-02-21 19:50:07 +00:00
|
|
|
set_pmd(pmd, __pmd(__pa(addr) | prot));
|
2020-07-22 09:45:51 +00:00
|
|
|
pages++;
|
|
|
|
continue;
|
2025-02-07 14:48:53 +00:00
|
|
|
} else if (!direct && cpu_has_edat1()) {
|
2020-07-22 09:45:52 +00:00
|
|
|
void *new_page;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Use 1MB frames for vmemmap if available. We
|
|
|
|
* always use large frames even if they are only
|
|
|
|
* partially used. Otherwise we would have also
|
|
|
|
* page tables since vmemmap_populate gets
|
|
|
|
* called for each section separately.
|
|
|
|
*/
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
new_page = vmemmap_alloc_block_buf(PMD_SIZE, NUMA_NO_NODE, altmap);
|
2020-07-22 09:45:56 +00:00
|
|
|
if (new_page) {
|
2022-02-21 19:50:07 +00:00
|
|
|
set_pmd(pmd, __pmd(__pa(new_page) | prot));
|
2020-07-22 09:45:57 +00:00
|
|
|
if (!IS_ALIGNED(addr, PMD_SIZE) ||
|
|
|
|
!IS_ALIGNED(next, PMD_SIZE)) {
|
2020-07-23 19:42:36 +00:00
|
|
|
vmemmap_use_new_sub_pmd(addr, next);
|
2020-07-22 09:45:57 +00:00
|
|
|
}
|
2020-07-22 09:45:56 +00:00
|
|
|
continue;
|
|
|
|
}
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
pte = vmem_pte_alloc();
|
|
|
|
if (!pte)
|
2007-10-22 10:52:48 +00:00
|
|
|
goto out;
|
2020-07-22 09:45:51 +00:00
|
|
|
pmd_populate(&init_mm, pmd, pte);
|
2024-03-05 04:37:47 +00:00
|
|
|
} else if (pmd_leaf(*pmd)) {
|
2020-07-22 09:45:57 +00:00
|
|
|
if (!direct)
|
|
|
|
vmemmap_use_sub_pmd(addr, next);
|
2012-10-08 07:18:26 +00:00
|
|
|
continue;
|
2020-07-22 09:45:57 +00:00
|
|
|
}
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
ret = modify_pte_table(pmd, addr, next, add, direct, altmap);
|
2020-07-22 09:45:52 +00:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
2020-07-22 09:45:55 +00:00
|
|
|
if (!add)
|
|
|
|
try_free_pte_table(pmd, addr & PMD_MASK);
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
out:
|
2020-07-22 09:45:52 +00:00
|
|
|
if (direct)
|
|
|
|
update_page_count(PG_DIRECT_MAP_1M, add ? pages : -pages);
|
2020-07-22 09:45:51 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:55 +00:00
|
|
|
static void try_free_pmd_table(pud_t *pud, unsigned long start)
|
|
|
|
{
|
|
|
|
pmd_t *pmd;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
pmd = pmd_offset(pud, start);
|
|
|
|
for (i = 0; i < PTRS_PER_PMD; i++, pmd++)
|
|
|
|
if (!pmd_none(*pmd))
|
|
|
|
return;
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
vmem_free_pages(pud_deref(*pud), CRST_ALLOC_ORDER, NULL);
|
2020-07-22 09:45:55 +00:00
|
|
|
pud_clear(pud);
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:51 +00:00
|
|
|
static int modify_pud_table(p4d_t *p4d, unsigned long addr, unsigned long end,
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
bool add, bool direct, struct vmem_altmap *altmap)
|
2020-07-22 09:45:51 +00:00
|
|
|
{
|
|
|
|
unsigned long next, prot, pages = 0;
|
|
|
|
int ret = -ENOMEM;
|
|
|
|
pud_t *pud;
|
|
|
|
pmd_t *pmd;
|
|
|
|
|
|
|
|
prot = pgprot_val(REGION3_KERNEL);
|
|
|
|
pud = pud_offset(p4d, addr);
|
|
|
|
for (; addr < end; addr = next, pud++) {
|
|
|
|
next = pud_addr_end(addr, end);
|
|
|
|
if (!add) {
|
|
|
|
if (pud_none(*pud))
|
|
|
|
continue;
|
2024-03-05 04:37:48 +00:00
|
|
|
if (pud_leaf(*pud)) {
|
2020-07-22 09:45:51 +00:00
|
|
|
if (IS_ALIGNED(addr, PUD_SIZE) &&
|
|
|
|
IS_ALIGNED(next, PUD_SIZE)) {
|
|
|
|
pud_clear(pud);
|
|
|
|
pages++;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
} else if (pud_none(*pud)) {
|
|
|
|
if (IS_ALIGNED(addr, PUD_SIZE) &&
|
|
|
|
IS_ALIGNED(next, PUD_SIZE) &&
|
2025-02-07 14:48:54 +00:00
|
|
|
cpu_has_edat2() && direct &&
|
2020-07-22 09:45:51 +00:00
|
|
|
!debug_pagealloc_enabled()) {
|
2022-02-21 19:50:07 +00:00
|
|
|
set_pud(pud, __pud(__pa(addr) | prot));
|
2020-07-22 09:45:51 +00:00
|
|
|
pages++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
pmd = vmem_crst_alloc(_SEGMENT_ENTRY_EMPTY);
|
|
|
|
if (!pmd)
|
2006-12-08 14:56:07 +00:00
|
|
|
goto out;
|
2020-07-22 09:45:51 +00:00
|
|
|
pud_populate(&init_mm, pud, pmd);
|
2024-03-05 04:37:48 +00:00
|
|
|
} else if (pud_leaf(*pud)) {
|
2008-04-30 11:38:46 +00:00
|
|
|
continue;
|
2020-07-23 19:42:36 +00:00
|
|
|
}
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
ret = modify_pmd_table(pud, addr, next, add, direct, altmap);
|
2020-07-22 09:45:51 +00:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
2020-07-22 09:45:55 +00:00
|
|
|
if (!add)
|
|
|
|
try_free_pmd_table(pud, addr & PUD_MASK);
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
out:
|
2020-07-22 09:45:52 +00:00
|
|
|
if (direct)
|
|
|
|
update_page_count(PG_DIRECT_MAP_2G, add ? pages : -pages);
|
2020-07-22 09:45:51 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:55 +00:00
|
|
|
static void try_free_pud_table(p4d_t *p4d, unsigned long start)
|
|
|
|
{
|
|
|
|
pud_t *pud;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
pud = pud_offset(p4d, start);
|
2020-07-23 19:42:36 +00:00
|
|
|
for (i = 0; i < PTRS_PER_PUD; i++, pud++) {
|
2020-07-22 09:45:55 +00:00
|
|
|
if (!pud_none(*pud))
|
|
|
|
return;
|
2020-07-23 19:42:36 +00:00
|
|
|
}
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
vmem_free_pages(p4d_deref(*p4d), CRST_ALLOC_ORDER, NULL);
|
2020-07-22 09:45:55 +00:00
|
|
|
p4d_clear(p4d);
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:51 +00:00
|
|
|
static int modify_p4d_table(pgd_t *pgd, unsigned long addr, unsigned long end,
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
bool add, bool direct, struct vmem_altmap *altmap)
|
2020-07-22 09:45:51 +00:00
|
|
|
{
|
|
|
|
unsigned long next;
|
|
|
|
int ret = -ENOMEM;
|
|
|
|
p4d_t *p4d;
|
|
|
|
pud_t *pud;
|
|
|
|
|
|
|
|
p4d = p4d_offset(pgd, addr);
|
|
|
|
for (; addr < end; addr = next, p4d++) {
|
|
|
|
next = p4d_addr_end(addr, end);
|
|
|
|
if (!add) {
|
|
|
|
if (p4d_none(*p4d))
|
|
|
|
continue;
|
|
|
|
} else if (p4d_none(*p4d)) {
|
|
|
|
pud = vmem_crst_alloc(_REGION3_ENTRY_EMPTY);
|
|
|
|
if (!pud)
|
|
|
|
goto out;
|
2020-08-21 16:27:36 +00:00
|
|
|
p4d_populate(&init_mm, p4d, pud);
|
2008-04-30 11:38:46 +00:00
|
|
|
}
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
ret = modify_pud_table(p4d, addr, next, add, direct, altmap);
|
2020-07-22 09:45:51 +00:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
2020-07-22 09:45:55 +00:00
|
|
|
if (!add)
|
|
|
|
try_free_pud_table(p4d, addr & P4D_MASK);
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:55 +00:00
|
|
|
static void try_free_p4d_table(pgd_t *pgd, unsigned long start)
|
|
|
|
{
|
|
|
|
p4d_t *p4d;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
p4d = p4d_offset(pgd, start);
|
2020-07-23 19:42:36 +00:00
|
|
|
for (i = 0; i < PTRS_PER_P4D; i++, p4d++) {
|
2020-07-22 09:45:55 +00:00
|
|
|
if (!p4d_none(*p4d))
|
|
|
|
return;
|
2020-07-23 19:42:36 +00:00
|
|
|
}
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
vmem_free_pages(pgd_deref(*pgd), CRST_ALLOC_ORDER, NULL);
|
2020-07-22 09:45:55 +00:00
|
|
|
pgd_clear(pgd);
|
|
|
|
}
|
|
|
|
|
2020-07-22 09:45:52 +00:00
|
|
|
static int modify_pagetable(unsigned long start, unsigned long end, bool add,
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
bool direct, struct vmem_altmap *altmap)
|
2020-07-22 09:45:51 +00:00
|
|
|
{
|
|
|
|
unsigned long addr, next;
|
|
|
|
int ret = -ENOMEM;
|
|
|
|
pgd_t *pgd;
|
|
|
|
p4d_t *p4d;
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(!PAGE_ALIGNED(start | end)))
|
|
|
|
return -EINVAL;
|
2023-09-01 06:11:14 +00:00
|
|
|
/* Don't mess with any tables not fully in 1:1 mapping & vmemmap area */
|
2024-03-01 06:05:39 +00:00
|
|
|
if (WARN_ON_ONCE(end > __abs_lowcore))
|
2023-09-01 06:11:14 +00:00
|
|
|
return -EINVAL;
|
2020-07-22 09:45:51 +00:00
|
|
|
for (addr = start; addr < end; addr = next) {
|
|
|
|
next = pgd_addr_end(addr, end);
|
|
|
|
pgd = pgd_offset_k(addr);
|
|
|
|
|
|
|
|
if (!add) {
|
|
|
|
if (pgd_none(*pgd))
|
|
|
|
continue;
|
|
|
|
} else if (pgd_none(*pgd)) {
|
|
|
|
p4d = vmem_crst_alloc(_REGION2_ENTRY_EMPTY);
|
|
|
|
if (!p4d)
|
2006-12-08 14:56:07 +00:00
|
|
|
goto out;
|
2020-07-22 09:45:51 +00:00
|
|
|
pgd_populate(&init_mm, pgd, p4d);
|
2006-12-08 14:56:07 +00:00
|
|
|
}
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
ret = modify_p4d_table(pgd, addr, next, add, direct, altmap);
|
2020-07-22 09:45:51 +00:00
|
|
|
if (ret)
|
|
|
|
goto out;
|
2020-07-22 09:45:55 +00:00
|
|
|
if (!add)
|
|
|
|
try_free_p4d_table(pgd, addr & PGDIR_MASK);
|
2006-12-08 14:56:07 +00:00
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
out:
|
2020-07-22 09:45:51 +00:00
|
|
|
if (!add)
|
|
|
|
flush_tlb_kernel_range(start, end);
|
2006-12-08 14:56:07 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
static int add_pagetable(unsigned long start, unsigned long end, bool direct,
|
|
|
|
struct vmem_altmap *altmap)
|
2020-07-22 09:45:51 +00:00
|
|
|
{
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
return modify_pagetable(start, end, true, direct, altmap);
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
static int remove_pagetable(unsigned long start, unsigned long end, bool direct,
|
|
|
|
struct vmem_altmap *altmap)
|
2020-07-22 09:45:51 +00:00
|
|
|
{
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
return modify_pagetable(start, end, false, direct, altmap);
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add a physical memory range to the 1:1 mapping.
|
|
|
|
*/
|
|
|
|
static int vmem_add_range(unsigned long start, unsigned long size)
|
|
|
|
{
|
2023-06-17 20:04:26 +00:00
|
|
|
start = (unsigned long)__va(start);
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
return add_pagetable(start, start + size, true, NULL);
|
2020-07-22 09:45:51 +00:00
|
|
|
}
|
|
|
|
|
2006-12-08 14:56:07 +00:00
|
|
|
/*
|
|
|
|
* Remove a physical memory range from the 1:1 mapping.
|
|
|
|
*/
|
|
|
|
static void vmem_remove_range(unsigned long start, unsigned long size)
|
|
|
|
{
|
2023-06-17 20:04:26 +00:00
|
|
|
start = (unsigned long)__va(start);
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
remove_pagetable(start, start + size, true, NULL);
|
2006-12-08 14:56:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add a backed mem_map array to the virtual mem_map array.
|
|
|
|
*/
|
2017-12-29 07:53:54 +00:00
|
|
|
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
|
2020-07-23 19:42:36 +00:00
|
|
|
struct vmem_altmap *altmap)
|
2006-12-08 14:56:07 +00:00
|
|
|
{
|
2020-07-22 09:45:53 +00:00
|
|
|
int ret;
|
|
|
|
|
2020-07-22 09:45:54 +00:00
|
|
|
mutex_lock(&vmem_mutex);
|
2020-07-22 09:45:52 +00:00
|
|
|
/* We don't care about the node, just use NUMA_NO_NODE on allocations */
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
ret = add_pagetable(start, end, false, altmap);
|
2020-07-22 09:45:53 +00:00
|
|
|
if (ret)
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
remove_pagetable(start, end, false, altmap);
|
2020-07-22 09:45:54 +00:00
|
|
|
mutex_unlock(&vmem_mutex);
|
2020-07-22 09:45:53 +00:00
|
|
|
return ret;
|
2006-12-08 14:56:07 +00:00
|
|
|
}
|
|
|
|
|
2023-10-16 10:17:59 +00:00
|
|
|
#ifdef CONFIG_MEMORY_HOTPLUG
|
|
|
|
|
2017-12-29 07:53:56 +00:00
|
|
|
void vmemmap_free(unsigned long start, unsigned long end,
|
2020-07-23 19:42:36 +00:00
|
|
|
struct vmem_altmap *altmap)
|
2013-02-23 00:33:08 +00:00
|
|
|
{
|
2020-07-22 09:45:54 +00:00
|
|
|
mutex_lock(&vmem_mutex);
|
s390/mm: allocate vmemmap pages from self-contained memory range
Allocate memory map (struct pages array) from the hotplugged memory
range, rather than using system memory. The change addresses the issue
where standby memory, when configured to be much larger than online
memory, could potentially lead to ipl failure due to memory map
allocation from online memory. For example, 16MB of memory map
allocation is needed for a memory block size of 1GB and when standby
memory is configured much larger than online memory, this could lead to
ipl failure.
To address this issue, the solution involves introducing "memmap on
memory" using the vmem_altmap structure on s390. Architectures that
want to implement it should pass the altmap to the vmemmap_populate()
function and its associated callchain. This enhancement is discussed in
commit 4b94ffdc4163 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Provide "memmap on memory" support for s390 by passing the altmap in
vmemmap_populate() and its callchain. The allocation path is described
as follows:
* When altmap is NULL in vmemmap_populate(), memory map allocation
occurs using the existing vmemmap_alloc_block_buf().
* When altmap is not NULL in vmemmap_populate(), memory map allocation
still uses vmemmap_alloc_block_buf(), but this function internally
calls altmap_alloc_block_buf().
For deallocation, the process is outlined as follows:
* When altmap is NULL in vmemmap_free(), memory map deallocation happens
through free_pages().
* When altmap is not NULL in vmemmap_free(), memory map deallocation
occurs via vmem_altmap_free().
While memory map allocation is primarily handled through the
self-contained memory map range, there might still be a small amount of
system memory allocation required for vmemmap pagetables. To mitigate
this impact, this feature will be limited to machines with EDAT1
support.
Link: https://lkml.kernel.org/r/20240108132747.3238763-3-sumanthk@linux.ibm.com
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-08 13:27:44 +00:00
|
|
|
remove_pagetable(start, end, false, altmap);
|
2020-07-22 09:45:54 +00:00
|
|
|
mutex_unlock(&vmem_mutex);
|
2013-02-23 00:33:08 +00:00
|
|
|
}
|
|
|
|
|
2023-10-16 10:17:59 +00:00
|
|
|
#endif
|
|
|
|
|
2020-06-25 15:00:29 +00:00
|
|
|
void vmem_remove_mapping(unsigned long start, unsigned long size)
|
2006-12-08 14:56:07 +00:00
|
|
|
{
|
|
|
|
mutex_lock(&vmem_mutex);
|
2020-06-25 15:00:29 +00:00
|
|
|
vmem_remove_range(start, size);
|
2006-12-08 14:56:07 +00:00
|
|
|
mutex_unlock(&vmem_mutex);
|
|
|
|
}
|
|
|
|
|
2021-02-26 01:17:41 +00:00
|
|
|
struct range arch_get_mappable_range(void)
|
|
|
|
{
|
|
|
|
struct range mhp_range;
|
|
|
|
|
|
|
|
mhp_range.start = 0;
|
s390/mm: rework arch_get_mappable_range() callback
As per description in mm/memory_hotplug.c platforms should define
arch_get_mappable_range() that provides maximum possible addressable
physical memory range for which the linear mapping could be created.
The current implementation uses VMEM_MAX_PHYS macro as the maximum
mappable physical address and it is simply a cast to vmemmap. Since
the address is in physical address space the natural upper limit of
MAX_PHYSMEM_BITS is honoured:
vmemmap_start = min(vmemmap_start, 1UL << MAX_PHYSMEM_BITS);
Further, to make sure the identity mapping would not overlay with
vmemmap, the size of identity mapping could be stripped like this:
ident_map_size = min(ident_map_size, vmemmap_start);
Similarily, any other memory that could be added (e.g DCSS segment)
should not overlay with vmemmap as well and that is prevented by
using vmemmap (VMEM_MAX_PHYS macro) as the upper limit.
However, while the use of VMEM_MAX_PHYS brings the desired result
it actually poses two issues:
1. As described, vmemmap is handled as a physical address, although
it is actually a pointer to struct page in virtual address space.
2. As vmemmap is a virtual address it could have been located
anywhere in the virtual address space. However, the desired
necessity to honour MAX_PHYSMEM_BITS limit prevents that.
Rework arch_get_mappable_range() callback in a way it does not
use VMEM_MAX_PHYS macro and does not confuse the notion of virtual
vs physical address spacees as result. That paves the way for moving
vmemmap elsewhere and optimizing the virtual address space layout.
Introduce max_mappable preserved boot variable and let function
setup_kernel_memory_layout() set it up. As result, the rest of the
code is does not need to know the virtual memory layout specifics.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-07-02 21:11:18 +00:00
|
|
|
mhp_range.end = max_mappable - 1;
|
2021-02-26 01:17:41 +00:00
|
|
|
return mhp_range;
|
|
|
|
}
|
|
|
|
|
2008-04-30 11:38:47 +00:00
|
|
|
int vmem_add_mapping(unsigned long start, unsigned long size)
|
2006-12-08 14:56:07 +00:00
|
|
|
{
|
2021-02-26 01:17:41 +00:00
|
|
|
struct range range = arch_get_mappable_range();
|
2006-12-08 14:56:07 +00:00
|
|
|
int ret;
|
|
|
|
|
2021-02-26 01:17:41 +00:00
|
|
|
if (start < range.start ||
|
|
|
|
start + size > range.end + 1 ||
|
2020-06-25 15:00:29 +00:00
|
|
|
start + size < start)
|
|
|
|
return -ERANGE;
|
2006-12-08 14:56:07 +00:00
|
|
|
|
2020-06-25 15:00:29 +00:00
|
|
|
mutex_lock(&vmem_mutex);
|
2020-07-22 09:45:50 +00:00
|
|
|
ret = vmem_add_range(start, size);
|
2006-12-08 14:56:07 +00:00
|
|
|
if (ret)
|
2020-06-25 15:00:29 +00:00
|
|
|
vmem_remove_range(start, size);
|
2006-12-08 14:56:07 +00:00
|
|
|
mutex_unlock(&vmem_mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-07-20 06:22:01 +00:00
|
|
|
/*
|
|
|
|
* Allocate new or return existing page-table entry, but do not map it
|
|
|
|
* to any physical address. If missing, allocate segment- and region-
|
|
|
|
* table entries along. Meeting a large segment- or region-table entry
|
|
|
|
* while traversing is an error, since the function is expected to be
|
2023-06-28 14:23:20 +00:00
|
|
|
* called against virtual regions reserved for 4KB mappings only.
|
2022-07-20 06:22:01 +00:00
|
|
|
*/
|
2022-07-24 13:02:16 +00:00
|
|
|
pte_t *vmem_get_alloc_pte(unsigned long addr, bool alloc)
|
2022-07-20 06:22:01 +00:00
|
|
|
{
|
|
|
|
pte_t *ptep = NULL;
|
|
|
|
pgd_t *pgd;
|
|
|
|
p4d_t *p4d;
|
|
|
|
pud_t *pud;
|
|
|
|
pmd_t *pmd;
|
|
|
|
pte_t *pte;
|
|
|
|
|
|
|
|
pgd = pgd_offset_k(addr);
|
|
|
|
if (pgd_none(*pgd)) {
|
|
|
|
if (!alloc)
|
|
|
|
goto out;
|
|
|
|
p4d = vmem_crst_alloc(_REGION2_ENTRY_EMPTY);
|
|
|
|
if (!p4d)
|
|
|
|
goto out;
|
|
|
|
pgd_populate(&init_mm, pgd, p4d);
|
|
|
|
}
|
|
|
|
p4d = p4d_offset(pgd, addr);
|
|
|
|
if (p4d_none(*p4d)) {
|
|
|
|
if (!alloc)
|
|
|
|
goto out;
|
|
|
|
pud = vmem_crst_alloc(_REGION3_ENTRY_EMPTY);
|
|
|
|
if (!pud)
|
|
|
|
goto out;
|
|
|
|
p4d_populate(&init_mm, p4d, pud);
|
|
|
|
}
|
|
|
|
pud = pud_offset(p4d, addr);
|
|
|
|
if (pud_none(*pud)) {
|
|
|
|
if (!alloc)
|
|
|
|
goto out;
|
|
|
|
pmd = vmem_crst_alloc(_SEGMENT_ENTRY_EMPTY);
|
|
|
|
if (!pmd)
|
|
|
|
goto out;
|
|
|
|
pud_populate(&init_mm, pud, pmd);
|
2024-03-05 04:37:48 +00:00
|
|
|
} else if (WARN_ON_ONCE(pud_leaf(*pud))) {
|
2022-07-20 06:22:01 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
pmd = pmd_offset(pud, addr);
|
|
|
|
if (pmd_none(*pmd)) {
|
|
|
|
if (!alloc)
|
|
|
|
goto out;
|
|
|
|
pte = vmem_pte_alloc();
|
|
|
|
if (!pte)
|
|
|
|
goto out;
|
|
|
|
pmd_populate(&init_mm, pmd, pte);
|
2024-03-05 04:37:47 +00:00
|
|
|
} else if (WARN_ON_ONCE(pmd_leaf(*pmd))) {
|
2022-07-20 06:22:01 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
ptep = pte_offset_kernel(pmd, addr);
|
|
|
|
out:
|
|
|
|
return ptep;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __vmem_map_4k_page(unsigned long addr, unsigned long phys, pgprot_t prot, bool alloc)
|
|
|
|
{
|
|
|
|
pte_t *ptep, pte;
|
|
|
|
|
|
|
|
if (!IS_ALIGNED(addr, PAGE_SIZE))
|
|
|
|
return -EINVAL;
|
|
|
|
ptep = vmem_get_alloc_pte(addr, alloc);
|
|
|
|
if (!ptep)
|
|
|
|
return -ENOMEM;
|
|
|
|
__ptep_ipte(addr, ptep, 0, 0, IPTE_GLOBAL);
|
|
|
|
pte = mk_pte_phys(phys, prot);
|
|
|
|
set_pte(ptep, pte);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int vmem_map_4k_page(unsigned long addr, unsigned long phys, pgprot_t prot)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
mutex_lock(&vmem_mutex);
|
|
|
|
rc = __vmem_map_4k_page(addr, phys, prot, true);
|
|
|
|
mutex_unlock(&vmem_mutex);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
void vmem_unmap_4k_page(unsigned long addr)
|
|
|
|
{
|
|
|
|
pte_t *ptep;
|
|
|
|
|
|
|
|
mutex_lock(&vmem_mutex);
|
|
|
|
ptep = virt_to_kpte(addr);
|
|
|
|
__ptep_ipte(addr, ptep, 0, 0, IPTE_GLOBAL);
|
|
|
|
pte_clear(&init_mm, addr, ptep);
|
|
|
|
mutex_unlock(&vmem_mutex);
|
|
|
|
}
|
|
|
|
|
2006-12-08 14:56:07 +00:00
|
|
|
void __init vmem_map_init(void)
|
|
|
|
{
|
2023-08-25 12:29:53 +00:00
|
|
|
__set_memory_rox(_stext, _etext);
|
|
|
|
__set_memory_ro(_etext, __end_rodata);
|
|
|
|
__set_memory_rox(__stext_amode31, __etext_amode31);
|
2023-08-25 12:29:50 +00:00
|
|
|
/*
|
|
|
|
* If the BEAR-enhancement facility is not installed the first
|
|
|
|
* prefix page is used to return to the previous context with
|
|
|
|
* an LPSWE instruction and therefore must be executable.
|
|
|
|
*/
|
2025-02-07 14:49:09 +00:00
|
|
|
if (!cpu_has_bear())
|
2023-08-25 12:29:48 +00:00
|
|
|
set_memory_x(0, 1);
|
2024-07-29 13:45:58 +00:00
|
|
|
if (debug_pagealloc_enabled())
|
2025-01-27 14:23:02 +00:00
|
|
|
__set_memory_4k(__va(0), absolute_pointer(__va(0)) + ident_map_size);
|
2016-03-22 09:54:24 +00:00
|
|
|
pr_info("Write protected kernel read-only data: %luk\n",
|
2017-11-08 10:18:29 +00:00
|
|
|
(unsigned long)(__end_rodata - _stext) >> 10);
|
2006-12-08 14:56:07 +00:00
|
|
|
}
|