- 20 Apr, 2023 6 commits
-
-
Heiko Carstens authored
Factor out the code that fills the stack with the stackleak poison value in order to allow architectures to provide a faster implementation. Acked-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Acked-by:
Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20230405130841.1350565-2-hca@linux.ibm.comSigned-off-by:
-
Heiko Carstens authored
All old style assembly annotations have been converted for s390. Select ARCH_USE_SYM_ANNOTATIONS to make sure the old macros like ENTRY() aren't available anymore. This prevents that new code which uses the old macros will be added again. This follows what has been done for x86 with commit 2ce0d7f9 ("x86/asm: Provide a Kconfig symbol for disabling old assembly annotations") and for arm64 with commit 50479d58 ("arm64: Disable old style assembly annotations"). Signed-off-by:
-
Heiko Carstens authored
Make use of the set_direct_map() calls for module allocations. In particular: - All changes to read-only permissions in kernel VA mappings are also applied to the direct mapping. Note that execute permissions are intentionally not applied to the direct mapping in order to make sure that all allocated pages within the direct mapping stay non-executable - module_alloc() passes the VM_FLUSH_RESET_PERMS to __vmalloc_node_range() to make sure that all implicit permission changes made to the direct mapping are reset when the allocated vm area is freed again Side effects: the direct mapping will be fragmented depending on how many vm areas with VM_FLUSH_RESET_PERMS and/or explicit page permission changes are allocated and freed again. For example, just after boot of a system the direct mapping statistics look like: $cat /proc/meminfo ... DirectMap4k: 111628 kB DirectMap1M: 16665600 kB DirectMap2G: 0 kB Acked-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
s390 supports ARCH_HAS_SET_DIRECT_MAP, therefore wire up the memfd_secret system call, which depends on it. Signed-off-by:
-
Heiko Carstens authored
Implement the set_direct_map_*() API, which allows to invalidate and set default permissions to pages within the direct mapping. Note that kernel_page_present(), which is also supposed to be part of this API, is intentionally not implemented. The reason for this is that kernel_page_present() is only used (and currently only makes sense) for suspend/resume, which isn't supported on s390. Reviewed-by:
-
Heiko Carstens authored
Use BIT macro to generate SET_MEMORY bit masks, which is easier to maintain if bits get added, or removed. Reviewed-by:
-
- 19 Apr, 2023 24 commits
-
-
Heiko Carstens authored
relocate_kernel.S seems to be the only assembler file which doesn't follow the standard way of indentation. Adjust this for the sake of consistency. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Acked-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by:
-
Heiko Carstens authored
The kasan mem*() functions are not used anymore since s390 has switched to GENERIC_ENTRY and commit 69d4c0d3 ("entry, kasan, x86: Disallow overriding mem*() functions"). Therefore remove the now dead code, similar to x86. While at it also use the SYM* macros in mem.S. Signed-off-by:
-
Alexander Gordeev authored
To allow calling of DAT-off code from kernel the stack needs to be switched to nodat_stack (or other stack mapped as 1:1). Before call_nodat() macro was introduced that was necessary to provide the very same memory address for STNSM and STOSM instructions. If the kernel would stay on a random stack (e.g. a virtually mapped one) then a virtual address provided for STNSM instruction could differ from the physical address needed for the corresponding STOSM instruction. After call_nodat() macro is introduced the kernel stack does not need to be mapped 1:1 anymore, since the macro stores the physical memory address of return PSW in a register before entering DAT-off mode. This way the return LPSWE instruction is able to pick the correct memory location and restore the DAT-on mode. That however might fail in case the 16-byte return PSW happened to cross page boundary: PSW mask and PSW address could end up in two separate non-contiguous physical pages. Align the return PSW on 16-byte boundary so it always fits into a single physical page. As result any stack (including the virtually mapped one) could be used for calling DAT-off code and prior switching to nodat_stack becomes unnecessary. Signed-off-by:
-
Alexander Gordeev authored
Calling kdump kernel is a two-step process that involves invocation of the purgatory code: first time - to verify the new kernel checksum and second time - to call the new kernel itself. The purgatory code operates on real addresses and does not expect any memory protection. Therefore, before the purgatory code is entered the DAT mode is always turned off. However, it is only restored upon return from the new kernel checksum verification. In case the purgatory was called to start the new kernel and failed the control is returned to the old kernel, but the DAT mode continues staying off. The new kernel start failure is unlikely and leads to the disabled wait state anyway. Still that poses a risk, since the kernel code in general is not DAT-off safe and even calling the disabled_wait() function might crash. Introduce call_nodat() macro that allows entering DAT-off mode, calling an arbitrary function and restoring DAT mode back on. Switch all invocations of DAT-off code to that macro and avoid the above described scenario altogether. Name the call_nodat() macro in small letters after the already existing call_on_stack() and put it to the same header file. Signed-off-by:
-
Alexander Gordeev authored
Fix virtual vs physical address confusion (which currently are the same). Signed-off-by:
-
Alexander Gordeev authored
Avoid unnecessary run-time and compile-time type conversions of do_start_kdump() function return value and parameter. Signed-off-by:
-
Alexander Gordeev authored
The kernel code is not guaranteed DAT-off mode safe. Turn the DAT mode off immediately before entering the purgatory. Further, to avoid subtle side effects reset the system immediately before turning DAT mode off while making all necessary preparations in advance. Signed-off-by:
-
Thomas Richter authored
Remove function validate_ctr_auth() and replace this very small function by its body. No functional change. Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Acked-by:
Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by:
-
Thomas Richter authored
Function validate_ctr_version() first parameter is a pointer to a large structure, but only member hw_perf_event::config is used. Supply this structure member value in the function invocation. No functional change. Signed-off-by:
-
Thomas Richter authored
The CPU measurement facility counter information instruction qctri() retrieves information about the available counter sets. The information varies between machine generations, but is constant when running on a particular machine. For example the CPU measurement facility counter first and second version numbers determine the amount of counters in a counter set. This information never changes. The counter sets are identical for all CPUs in the system. It does not matter which CPU performs the instruction. Authorization control of the CPU Measurement facility can only be changed in the activation profile while the LPAR is not running. Retrieve the CPU measurement counter information at device driver initialization time and use its constant values. Function validate_ctr_version() verifies if a user provided CPU Measurement counter facility counter is valid and defined. It now uses the newly introduced static CPU counter facility information. To avoid repeated recalculation of the counter set sizes (numbers of counters per set), which never changes on a running machine, calculate the counter set size once at device driver initialization and store the result in an array. Functions cpum_cf_make_setsize() and cpum_cf_read_setsize() are introduced. Finally remove cpu_cf_events::info member and use the static CPU counter facility information instead. Signed-off-by:
-
Harald Freudenberger authored
Review and rework all the zero length array occurrences within structs to flexible array fields or comment if not used at all. However, some struct fields are there for documentation purpose or to have correct sizeof() evaluation of a struct and thus should not get deleted. Signed-off-by:
Holger Dengler <dengler@linux.ibm.com> Signed-off-by:
-
- 13 Apr, 2023 10 commits
-
-
Heiko Carstens authored
There are numerous patches which convert zero-length arrays with a flexible-array member. Convert the remaining s390 occurrences. Suggested-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://github.com/KSPP/linux/issues/78 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.htmlSigned-off-by:
-
Heiko Carstens authored
There are numerous patches which convert zero-length arrays with a flexible-array member. Convert the remaining s390 occurrences. Suggested-by:
-
Heiko Carstens authored
There are numerous patches which convert zero-length arrays with a flexible-array member. Convert the remaining s390 occurrences. Suggested-by:
-
Gustavo A. R. Silva authored
Zero-length arrays are deprecated [1] and have to be replaced by C99 flexible-array members. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help to make progress towards globally enabling -fstrict-flex-arrays=3 [2] Link: https://github.com/KSPP/linux/issues/78 [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2] Signed-off-by:
-
Gustavo A. R. Silva authored
Zero-length arrays are deprecated [1] and have to be replaced by C99 flexible-array members. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help to make progress towards globally enabling -fstrict-flex-arrays=3 [2] Link: https://github.com/KSPP/linux/issues/78 [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2] Signed-off-by:
-
Heiko Carstens authored
Commit bb1520d5 ("s390/mm: start kernel with DAT enabled") did not implement direct map accounting in the early page table setup code. In result the reported values are bogus now: $cat /proc/meminfo ... DirectMap4k: 5120 kB DirectMap1M: 18446744073709546496 kB DirectMap2G: 0 kB Fix this by adding the missing accounting. The result looks sane again: $cat /proc/meminfo ... DirectMap4k: 6156 kB DirectMap1M: 2091008 kB DirectMap2G: 6291456 kB Fixes: bb1520d5 ("s390/mm: start kernel with DAT enabled") Reviewed-by:
-
Heiko Carstens authored
Architectures generally use the "direct map" wording for mapping the whole physical memory. Use that wording as well in arch/s390/boot/vmem.c, instead of "one to one" in order to avoid confusion. This also matches what is already done in arch/s390/mm/vmem.c. Reviewed-by:
-
Marc Hartmayer authored
Use proper quoting for the variables and explicitly distinguish between command options and positional arguments. Acked-by:
Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by:
-
Thomas Richter authored
Simplify pr_err() statement into one line and omit return statement. No functional change. Signed-off-by:
-
Vasily Gorbik authored
When the KASLR is enabled, randomize the base address of the amode31 image within the first 2 GB, similar to the approach taken for the vmlinux image. This makes it harder to predict the location of amode31 data and code. Reviewed-by:
-
