linux-stable.git/arch/s390/kernel/Makefile, branch linux-rolling-stable

s390/vdso: Rename vdso64 to vdso

2025-11-25T14:28:07+00:00

Since compat is gone there is only a 64 bit vdso left.
Remove the superfluous "64" suffix everywhere.

Reviewed-by: Jens Remus 
Signed-off-by: Heiko Carstens

s390: Rename head64.S to head.S

2025-11-25T14:28:07+00:00

All the code is 64 bit, therefore remove the superfluous suffix.

Reviewed-by: Jens Remus 
Signed-off-by: Heiko Carstens

s390: Add stackprotector support

2025-11-24T10:45:21+00:00

Stackprotector support was previously unavailable on s390 because by
default compilers generate code which is not suitable for the kernel:
the canary value is accessed via thread local storage, where the address
of thread local storage is within access registers 0 and 1.

Using those registers also for the kernel would come with a significant
performance impact and more complicated kernel entry/exit code, since
access registers contents would have to be exchanged on every kernel entry
and exit.

With the upcoming gcc 16 release new compiler options will become available
which allow to generate code suitable for the kernel. [1]

Compiler option -mstack-protector-guard=global instructs gcc to generate
stackprotector code that refers to a global stackprotector canary value via
symbol __stack_chk_guard. Access to this value is guaranteed to occur via
larl and lgrl instructions.

Furthermore, compiler option -mstack-protector-guard-record generates a
section containing all code addresses that reference the canary value.

To allow for per task canary values the instructions which load the address
of __stack_chk_guard are patched so they access a lowcore field instead: a
per task canary value is available within the task_struct of each task, and
is written to the per-cpu lowcore location on each context switch.

Also add sanity checks and debugging option to be consistent with other
kernel code patching mechanisms.

Full debugging output can be enabled with the following kernel command line
options:

debug_stackprotector
bootdebug
ignore_loglevel
earlyprintk
dyndbg="file stackprotector.c +p"

Example debug output:

stackprot: 0000021e402d4eda: c010005a9ae3 -> c01f00070240

where ":  -> ".

[1] gcc commit 0cd1f03939d5 ("s390: Support global stack protector")

Reviewed-by: Sven Schnelle 
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/pai: Rename perf_pai_crypto.c to perf_pai.c

2025-11-14T10:30:08+00:00

Rename perf_pai_crypto.c to perf_pai.c. The new perf_pai.c
contains both PAI device drivers:
 - pai_crypto for PAI crypto counter set
 - pai_ext for PAI NNPA counter set
The rename reflects this common driver supporting both PMUs.

Signed-off-by: Thomas Richter 
Reviewed-by: Jan Polensky 
Signed-off-by: Heiko Carstens

s390/pai_crypto: Merge pai_ext PMU into pai_crypto

2025-11-14T10:30:07+00:00

Combine PAI cryptography and PAI extension (NNPA) PMUs in one driver.
Remove file perf_pai_ext.c and registration of PMU "pai_ext"
from perf_pai_crypto.c.

Includes:
- Shared alloc/free and sched_task handling
- NNPA events with exclude_kernel enforced, exclude_user rejected
- Setup CR0 bits for both PMUs

Signed-off-by: Thomas Richter 
Reviewed-by: Jan Polensky 
Signed-off-by: Heiko Carstens

s390/skey: Provide infrastructure for executing with non-default access key

2025-06-29T11:12:02+00:00

The current assumption is that kernel code is always executed with access
key zero, which means that storage key protection does not apply.

However this assumption is not correct: cmpxchg_user_key() may be executed
with a non-zero key; if then the storage key of the page which belongs to
the cmpxchg_user_key() code contains a key with fetch-protection enabled
the result is a protection exception.

For several performance optimizations storage keys are not initialized on
system boot. To keep these optimizations add infrastructure which allows to
define code ranges within functions which are executed with a non-default
key. When such code is executed such functions must explicitly call
skey_regions_initialize().

This will initialize all storage keys belonging to such code ranges in a
way that no protection exceptions happen when the code is executed with a
non-default access key.

Reviewed-by: Claudio Imbrenda 
Signed-off-by: Heiko Carstens 
Signed-off-by: Alexander Gordeev

arch: use always-$(KBUILD_BUILTIN) for vmlinux.lds

2025-06-07T05:38:07+00:00

The extra-y syntax is deprecated. Instead, use always-$(KBUILD_BUILTIN),
which behaves equivalently.

Signed-off-by: Masahiro Yamada 
Acked-by: Johannes Berg 
Reviewed-by: Nicolas Schier

s390/diag: Move diag.c to diag specific folder

2024-12-17T11:46:14+00:00

Move implementation of s390 diagnose code to diag specific folder.

Reviewed-by: Heiko Carstens 
Signed-off-by: Sumanth Korikkar 
Signed-off-by: Alexander Gordeev

s390/diag324: Retrieve power readings via diag 0x324

2024-12-17T11:46:14+00:00

Retrieve electrical power readings for resources in a computing
environment via diag 0x324. diag 0x324 stores the power readings in the
power information block (pib).

Provide power readings from pib via diag324 ioctl interface.  diag324
ioctl provides new pib to the user only if the threshold time has passed
since the last call. Otherwise, cache data is returned. When there are
no active readers, cleanup of pib buffer is performed.

Reviewed-by: Heiko Carstens 
Signed-off-by: Sumanth Korikkar 
Signed-off-by: Alexander Gordeev