aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-04-19s390/purgatory: use SYM* macros instead of ENTRY(), etc.Heiko Carstens2-51/+25
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/kprobes: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-2/+2
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/reipl: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-5/+5
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/head64: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-4/+4
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/earlypgm: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-2/+2
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/mcount: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-6/+4
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/crc32le: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-14/+16
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/crc32be: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-8/+9
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/crypto,chacha: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-23/+24
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Acked-by: Harald Freudenberger <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/amode31: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-44/+31
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/lib: use SYM* macros instead of ENTRY(), etc.Heiko Carstens1-2/+2
Consistently use the SYM* family of macros instead of the deprecated ENTRY(), ENDPROC(), etc. family of macros. Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/kasan: remove override of mem*() functionsHeiko Carstens2-21/+18
The kasan mem*() functions are not used anymore since s390 has switched to GENERIC_ENTRY and commit 69d4c0d32186 ("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: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/kdump: remove nodat stack restriction for calling nodat functionsAlexander Gordeev2-12/+5
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 <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/kdump: rework invocation of DAT-off codeAlexander Gordeev2-14/+61
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 <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> [[email protected]: some small modifications to call_nodat() macro] Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/kdump: fix virtual vs physical address confusionAlexander Gordeev1-8/+7
Fix virtual vs physical address confusion (which currently are the same). Signed-off-by: Alexander Gordeev <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/kdump: cleanup do_start_kdump() prototype and usageAlexander Gordeev1-4/+3
Avoid unnecessary run-time and compile-time type conversions of do_start_kdump() function return value and parameter. Signed-off-by: Alexander Gordeev <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/kexec: turn DAT mode off immediately before purgatoryAlexander Gordeev1-4/+3
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: Alexander Gordeev <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/cpum_cf: remove function validate_ctr_auth() by inline codeThomas Richter1-22/+9
Remove function validate_ctr_auth() and replace this very small function by its body. No functional change. Signed-off-by: Thomas Richter <[email protected]> Acked-by: Heiko Carstens <[email protected]> Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/cpum_cf: provide counter number to validate_ctr_version()Thomas Richter1-10/+8
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 <[email protected]> Acked-by: Heiko Carstens <[email protected]> Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/cpum_cf: introduce static CPU counter facility informationThomas Richter1-67/+65
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: Thomas Richter <[email protected]> Acked-by: Heiko Carstens <[email protected]> Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-19s390/zcrypt: rework arrays with length zero occurrencesHarald Freudenberger4-42/+40
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: Harald Freudenberger <[email protected]> Acked-by: Heiko Carstens <[email protected]> Reviewed-by: Holger Dengler <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/cio: replace zero-length array with flexible-array memberHeiko Carstens2-2/+2
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 <[email protected]> Link: https://github.com/KSPP/linux/issues/78 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/sclp: replace zero-length array with flexible-array memberHeiko Carstens2-2/+2
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 <[email protected]> Link: https://github.com/KSPP/linux/issues/78 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/debug: replace zero-length array with flexible-array memberHeiko Carstens1-1/+1
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 <[email protected]> Link: https://github.com/KSPP/linux/issues/78 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/fcx: replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
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 <[email protected]> Link: https://lore.kernel.org/r/ZC7XT5prvoE4Yunm@work Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/diag: replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
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 <[email protected]> Link: https://lore.kernel.org/r/ZC7XGpUtVhqlRLhH@work Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/mm: fix direct map accountingHeiko Carstens3-4/+18
Commit bb1520d581a3 ("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: bb1520d581a3 ("s390/mm: start kernel with DAT enabled") Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/mm: rename POPULATE_ONE2ONE to POPULATE_DIRECTHeiko Carstens1-4/+4
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: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/boot: improve install.sh scriptMarc Hartmayer1-4/+4
Use proper quoting for the variables and explicitly distinguish between command options and positional arguments. Acked-by: Heiko Carstens <[email protected]> Signed-off-by: Marc Hartmayer <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/cpum_cf: simplify pr_err() statement in cpumf_pmu_enable/disableThomas Richter1-14/+8
Simplify pr_err() statement into one line and omit return statement. No functional change. Signed-off-by: Thomas Richter <[email protected]> Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/kaslr: randomize amode31 base addressVasily Gorbik1-2/+4
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: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/kaslr: generalize and improve random base distributionVasily Gorbik4-11/+112
Improve the distribution algorithm of random base address to ensure a uniformity among all suitable addresses. To generate a random value once, and to build a continuous range in which every value is suitable, count all the suitable addresses (referred to as positions) that can be used as a base address. The positions are counted by iterating over the usable memory ranges. For each range that is big enough to accommodate the image, count all the suitable addresses where the image can be placed, while taking reserved memory ranges into consideration. A new function "iterate_valid_positions()" has dual purpose. Firstly, it is called to count the positions in a given memory range, and secondly, to convert a random position back to an address. "get_random_base()" has been replaced with more generic "randomize_within_range()" which now could be called for randomizing base addresses not just for the kernel image. Acked-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/boot: pin amode31 default lmaVasily Gorbik1-1/+3
The special amode31 part of the kernel must always remain below 2Gb. Place it just under vmlinux.default_lma by default, which makes it easier to debug amode31 as its default lma is known 0x10000 - 0x3000 (currently, amode31's size is 3 pages). This location is always available as it is originally occupied by the vmlinux archive. Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/boot: do not change default_lmaVasily Gorbik1-13/+12
The current modification of the default_lma is illogical and should be avoided. It would be more appropriate to introduce and utilize a new variable vmlinux_lma instead, so that default_lma remains unchanged and at its original "default" value of 0x100000. Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/cpum_cf: remove unnecessary copy_from_user callThomas Richter1-5/+1
Struct s390_ctrset_read userdata is filled by ioctl_read operation using put_user/copy_to_user. However, the ctrset->data value access is not performed anywhere during the ioctl_read operation. Remove unnecessary copy_from_user() call. No functional change. Signed-off-by: Thomas Richter <[email protected]> Suggested-by: Sumanth Korikkar <[email protected]> Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/cpum_cf: log bad return code of function cfset_all_copyThomas Richter1-6/+9
When function cfset_all_copy() fails, also log the bad return code in the debug statement (when turned on). No functional change Signed-off-by: Thomas Richter <[email protected]> Acked-by: Sumanth Korikkar <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/module: create module allocations without exec permissionsHeiko Carstens1-1/+1
This is the s390 variant of commit 7dfac3c5f40e ("arm64: module: create module allocations without exec permissions"): "The core code manages the executable permissions of code regions of modules explicitly. It is no longer necessary to create the module vmalloc regions with RWX permissions. So create them with RW- permissions instead, which is preferred from a security perspective." Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/ftrace: do not assume module_alloc() returns executable memoryHeiko Carstens2-2/+2
The ftrace code assumes at two places that module_alloc() returns executable memory. While this is currently true, this will be changed with a subsequent patch to follow other architectures which implement ARCH_HAS_STRICT_MODULE_RWX. Acked-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/mm: use set_memory_*() helpers instead of open codingHeiko Carstens3-24/+17
Given that set_memory_rox() and set_memory_rwnx() exist, it is possible to get rid of all open coded __set_memory() usages and replace them with proper helper calls everywhere. Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/mm: implement set_memory_rwnx()Heiko Carstens1-0/+5
Given that set_memory_rox() is implemented, provide also set_memory_rwnx(). This allows to get rid of all open coded __set_memory() usages in s390 architecture code. Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/mm: implement set_memory_rox()Heiko Carstens1-0/+6
Provide the s390 specific native set_memory_rox() implementation to avoid frequent set_memory_ro(); set_memory_x() call pairs. This is the s390 variant of commit 60463628c9e0 ("x86/mm: Implement native set_memory_rox()"). Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/ipl: fix physical-virtual confusion for diag308Nico Boehr1-3/+3
Diag 308 subcodes expect a physical address as their parameter. This currently is not a bug, but in the future physical and virtual addresses might differ. Fix the confusion by doing a virtual-to-physical conversion in the exported diag308() and leave the assembly wrapper __diag308() alone. Note that several callers pass NULL as addr, so check for the case when NULL is passed and pass 0 to hardware since virt_to_phys(0) might be nonzero. Suggested-by: Marc Hartmayer <[email protected]> Signed-off-by: Nico Boehr <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/kaslr: randomize module base load addressHeiko Carstens1-1/+21
Randomize the load address of modules in the kernel to make KASLR effective for modules. This is the s390 variant of commit e2b32e678513 ("x86, kaslr: randomize module base load address"). Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/kaslr: provide kaslr_enabled() functionHeiko Carstens6-8/+15
Just like other architectures provide a kaslr_enabled() function, instead of directly accessing a global variable. Also pass the renamed __kaslr_enabled variable from the decompressor to the kernel, so that kalsr_enabled() is available there too. This will be used by a subsequent patch which randomizes the module base load address. Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/checksum: remove not needed uaccess.h includeHeiko Carstens1-1/+0
Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-13s390/checksum: always use cksm instructionHeiko Carstens2-11/+2
Commit dfe843dce775 ("s390/checksum: support GENERIC_CSUM, enable it for KASAN") switched s390 to use the generic checksum functions, so that KASAN instrumentation also works checksum functions by avoiding architecture specific inline assemblies. There is however the problem that the generic csum_partial() function returns a 32 bit value with a 16 bit folded checksum, while the original s390 variant does not fold to 16 bit. This in turn causes that the ipib_checksum in lowcore contains different values depending on kernel config options. The ipib_checksum is used by system dumpers to verify if pointers in lowcore point to valid data. Verification is done by comparing checksum values. The system dumpers still use 32 bit checksum values which are not folded, and therefore the checksum verification fails (incorrectly). Symptom is that reboot after dump does not work anymore when a KASAN instrumented kernel is dumped. Fix this by not using the generic checksum implementation. Instead add an explicit kasan_check_read() so that KASAN knows about the read access from within the inline assembly. Reported-by: Alexander Egorenkov <[email protected]> Fixes: dfe843dce775 ("s390/checksum: support GENERIC_CSUM, enable it for KASAN") Tested-by: Alexander Egorenkov <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-04s390: enable HAVE_ARCH_STACKLEAKHeiko Carstens2-0/+11
Add support for the stackleak feature. Whenever the kernel returns to user space the kernel stack is filled with a poison value. Enabling this feature is quite expensive: e.g. after instrumenting the getpid() system call function to have a 4kb stack the result is an increased runtime of the system call by a factor of 3. Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-04s390: move on_thread_stack() to processor.hHeiko Carstens2-5/+7
As preparation for the stackleak feature move on_thread_stack() to processor.h like x86. Also make it __always_inline, and slightly optimize it by reading current task's kernel stack pointer from lowcore. Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-04s390: remove arch_early_irq_init()Heiko Carstens2-12/+2
Allocate early async stack like other early stacks and get rid of arch_early_irq_init(). This way the async stack is allocated earlier, and handled like all other stacks. Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2023-04-04s390/stacktrace: remove call_on_stack_noreturn()Heiko Carstens1-13/+0
There is no user left of call_on_stack_noreturn() - remove it. Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>