kernel/linux.git/arch/s390/include/asm/processor.h, branch v6.19.11

s390/stackleak: Fix __stackleak_poison() inline assembly constraint

2026-03-19T15:15:21+00:00

commit 674c5ff0f440a051ebf299d29a4c013133d81a65 upstream. The __stackleak_poison() inline assembly comes with a "count" operand where the "d" constraint is used. "count" is used with the exrl instruction and "d" means that the compiler may allocate any register from 0 to 15. If the compiler would allocate register 0 then the exrl instruction would not or the value of "count" into the executed instruction - resulting in a stackframe which is only partially poisoned. Use the correct "a" constraint, which excludes register 0 from register allocation. Fixes: 2a405f6bb3a5 ("s390/stackleak: provide fast __stackleak_poison() implementation") Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens Reviewed-by: Vasily Gorbik Link: https://lore.kernel.org/r/20260302133500.1560531-4-hca@linux.ibm.com Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman

s390/syscalls: Remove system call table pointer from thread_struct

2025-11-17T10:10:39+00:00

With compat support gone there is only one system call table left. Therefore remove the sys_call_table pointer from thread_struct and use the sys_call_table directly. Reviewed-by: Arnd Bergmann Signed-off-by: Heiko Carstens

s390: Remove compat support

2025-11-17T10:10:38+00:00

There shouldn't be any 31 bit code around anymore that matters. Remove the compat layer support required to run 31 bit code. Reason for removal is code simplification and reduced test effort. Note that this comes without any deprecation warnings added to config options, or kernel messages, since most likely those would be ignored anyway. If it turns out there is still a reason to keep the compat layer this can be reverted at any time in the future. Reviewed-by: Arnd Bergmann Signed-off-by: Heiko Carstens

s390/processor: Add __forward_psw() helper

2025-11-14T10:34:28+00:00

Similar to __rewind_psw() add the counter part __forward_psw(). This helps to make code more readable if a PSW address has to be forwarded, since it is more natural to write addr = __forward_psw(psw, ilen); instead of addr = __rewind_psw(psw, -ilen); This renames also the ilc parameter of __rewind_psw() to ilen, since the parameter reflects an instruction length, and not an instruction length code. Also change the type of ilen from unsigned long to long so it reflects that lengths can be negative or positive. Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens

s390: Remove superfluous newlines from inline assemblies

2025-09-29T11:52:08+00:00

Remove superfluous newlines from inline assemblies. Compilers use the number of lines of inline assemblies as heuristic for the complexity and inline decisions. Therefore inline assemblies should only contain as many lines as required. A lot of inline assemblies contain a superfluous newline for the last line. Remove such newlines to improve compiler inlining decisions. Suggested-by: Juergen Christ Signed-off-by: Heiko Carstens Reviewed-by: Alexander Gordeev Reviewed-by: Juergen Christ Signed-off-by: Alexander Gordeev

s390: Replace ASSEMBLY with ASSEMBLER in non-uapi headers

2025-06-16T14:23:02+00:00

While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembler code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This is bad since macros starting with two underscores are names that are reserved by the C language. It can also be very confusing for the developers when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's now standardize on the __ASSEMBLER__ macro that is provided by the compilers. This is a completely mechanical patch (done with a simple "sed -i" statement), with some manual fixups done later while rebasing the patch. Signed-off-by: Thomas Huth Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20250611140046.137739-3-thuth@redhat.com Signed-off-by: Alexander Gordeev

s390/processor: Use bitop functions for cpu flag helper functions

2025-03-31T10:20:39+00:00

Use bitop functions to implement cpu flag helper functions. This way it is guaranteed that bits cannot get lost if modified in different contexts on a cpu. E.g. if process context is interrupted in the middle of a read-modify-write sequence while modifying cpu flags, and within interrupt context cpu flags are also modified, bits can get lost. There is currently no code which is doing this, however upcoming code could potentially run into this problem. Acked-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik

s390: Use inline qualifier for all EX_TABLE and ALTERNATIVE inline assemblies

2025-03-18T16:13:51+00:00

Use asm_inline for all inline assemblies which make use of the EX_TABLE or ALTERNATIVE macros. These macros expand to many lines and the compiler assumes the number of lines within an inline assembly is the same as the number of instructions within an inline assembly. This has an effect on inlining and loop unrolling decisions. In order to avoid incorrect assumptions use asm_inline, which tells the compiler that an inline assembly has the smallest possible size. In order to avoid confusion when asm_inline should be used or not, since a couple of inline assemblies are quite large: the rule is to always use asm_inline whenever the EX_TABLE or ALTERNATIVE macro is used. In specific cases there may be reasons to not follow this guideline, but that should be documented with the corresponding code. Using the inline qualifier everywhere has only a small effect on the kernel image size: add/remove: 0/10 grow/shrink: 19/8 up/down: 1492/-1858 (-366) The only location where this seems to matter is load_unaligned_zeropad() from word-at-a-time.h where the compiler inlines more functions within the dcache code, which is indeed code where performance matters. Suggested-by: Juergen Christ Reviewed-by: Juergen Christ Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik

s390/stackleak: Use exrl instead of ex in __stackleak_poison()

2025-01-13T08:50:17+00:00

exrl is present in all machines currently supported, therefore prefer it over ex. This saves one instruction and doesn't need an additional register to hold the address of the target instruction. Signed-off-by: Sven Schnelle Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev

s390/mm/fault: Handle guest-related program interrupts in KVM

2024-10-29T10:49:18+00:00

Any program interrupt that happens in the host during the execution of a KVM guest will now short circuit the fault handler and return to KVM immediately. Guest fault handling (including pfault) will happen entirely inside KVM. When sie64a() returns zero, current->thread.gmap_int_code will contain the program interrupt number that caused the exit, or zero if the exit was not caused by a host program interrupt. KVM will now take care of handling all guest faults in vcpu_post_run(). Since gmap faults will not be visible by the rest of the kernel, remove GMAP_FAULT, the linux fault handlers for secure execution faults, the exception table entries for the sie instruction, the nop padding after the sie instruction, and all other references to guest faults from the s390 code. Signed-off-by: Claudio Imbrenda Co-developed-by: Heiko Carstens Link: https://lore.kernel.org/r/20241022120601.167009-6-imbrenda@linux.ibm.com Signed-off-by: Heiko Carstens