linux-stable.git/arch/s390/include, branch linux-5.4.y

s390/time: Use monotonic clock in get_cycles()

2025-08-28T14:21:26+00:00

[ Upstream commit 09e7e29d2b49ba84bcefb3dc1657726d2de5bb24 ]

Otherwise the code might not work correctly when the clock
is changed.

Signed-off-by: Sven Schnelle 
Reviewed-by: Heiko Carstens 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/futex: Fix FUTEX_OP_ANDN implementation

2025-03-13T11:43:06+00:00

commit 26701574cee6777f867f89b4a5c667817e1ee0dd upstream.

The futex operation FUTEX_OP_ANDN is supposed to implement

*(int *)UADDR2 &= ~OPARG;

The s390 implementation just implements an AND instead of ANDN.
Add the missing bitwise not operation to oparg to fix this.

This is broken since nearly 19 years, so it looks like user space is
not making use of this operation.

Fixes: 3363fbdd6fb4 ("[PATCH] s390: futex atomic operations")
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens 
Acked-by: Alexander Gordeev 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Greg Kroah-Hartman

s390/facility: Disable compile time optimization for decompressor code

2024-11-08T15:20:44+00:00

[ Upstream commit 0147addc4fb72a39448b8873d8acdf3a0f29aa65 ]

Disable compile time optimizations of test_facility() for the
decompressor. The decompressor should not contain any optimized code
depending on the architecture level set the kernel image is compiled
for to avoid unexpected operation exceptions.

Add a __DECOMPRESSOR check to test_facility() to enforce that
facilities are always checked during runtime for the decompressor.

Reviewed-by: Sven Schnelle 
Signed-off-by: Heiko Carstens 
Signed-off-by: Sasha Levin

s390/uv: Panic for set and remove shared access UVC errors

2024-09-04T11:14:51+00:00

[ Upstream commit cff59d8631e1409ffdd22d9d717e15810181b32c ]

The return value uv_set_shared() and uv_remove_shared() (which are
wrappers around the share() function) is not always checked. The system
integrity of a protected guest depends on the Share and Unshare UVCs
being successful. This means that any caller that fails to check the
return value will compromise the security of the protected guest.

No code path that would lead to such violation of the security
guarantees is currently exercised, since all the areas that are shared
never get unshared during the lifetime of the system. This might
change and become an issue in the future.

The Share and Unshare UVCs can only fail in case of hypervisor
misbehaviour (either a bug or malicious behaviour). In such cases there
is no reasonable way forward, and the system needs to panic.

This patch replaces the return at the end of the share() function with
a panic, to guarantee system integrity.

Fixes: 5abb9351dfd9 ("s390/uv: introduce guest side ultravisor code")
Signed-off-by: Claudio Imbrenda 
Reviewed-by: Christian Borntraeger 
Reviewed-by: Steffen Eiden 
Reviewed-by: Janosch Frank 
Link: https://lore.kernel.org/r/20240801112548.85303-1-imbrenda@linux.ibm.com
Message-ID: <20240801112548.85303-1-imbrenda@linux.ibm.com>
[frankja@linux.ibm.com: Fixed up patch subject]
Signed-off-by: Janosch Frank 
Signed-off-by: Sasha Levin

s390: Mark psw in __load_psw_mask() as __unitialized

2024-07-18T09:40:54+00:00

[ Upstream commit 7278a8fb8d032dfdc03d9b5d17e0bc451cdc1492 ]

Without __unitialized, the following code is generated when
INIT_STACK_ALL_ZERO is enabled:

86: d7 0f f0 a0 f0 a0     xc      160(16,%r15), 160(%r15)
8c: e3 40 f0 a0 00 24     stg     %r4, 160(%r15)
92: c0 10 00 00 00 08     larl    %r1, 0xa2
98: e3 10 f0 a8 00 24     stg     %r1, 168(%r15)
9e: b2 b2 f0 a0           lpswe   160(%r15)

The xc is not adding any security because psw is fully initialized
with the following instructions. Add __unitialized to the psw
definitiation to avoid the superfluous clearing of psw.

Reviewed-by: Heiko Carstens 
Signed-off-by: Sven Schnelle 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/pci: fix max size calculation in zpci_memcpy_toio()

2024-01-25T22:34:32+00:00

[ Upstream commit 80df7d6af7f6d229b34cf237b2cc9024c07111cd ]

The zpci_get_max_write_size() helper is used to determine the maximum
size a PCI store or load can use at a given __iomem address.

For the PCI block store the following restrictions apply:

1. The dst + len must not cross a 4K boundary in the (pseudo-)MMIO space
2. len must not exceed ZPCI_MAX_WRITE_SIZE
3. len must be a multiple of 8 bytes
4. The src address must be double word (8 byte) aligned
5. The dst address must be double word (8 byte) aligned

Otherwise only a normal PCI store which takes its src value from
a register can be used. For these PCI store restriction 1 still applies.
Similarly 1 also applies to PCI loads.

It turns out zpci_max_write_size() instead implements stricter
conditions which prevents PCI block stores from being used where they
can and should be used. In particular instead of conditions 4 and 5 it
wrongly enforces both dst and src to be size aligned. This indirectly
covers condition 1 but also prevents many legal PCI block stores.

On top of the functional shortcomings the zpci_get_max_write_size() is
misnamed as it is used for both read and write size calculations. Rename
it to zpci_get_max_io_size() and implement the listed conditions
explicitly.

Reviewed-by: Matthew Rosato 
Fixes: cd24834130ac ("s390/pci: base support")
Signed-off-by: Niklas Schnelle 
[agordeev@linux.ibm.com replaced spaces with tabs]
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/vx: fix save/restore of fpu kernel context

2024-01-08T10:29:43+00:00

[ Upstream commit e6b2dab41888332bf83f592131e7ea07756770a4 ]

The KERNEL_FPR mask only contains a flag for the first eight vector
registers. However floating point registers overlay parts of the first
sixteen vector registers.

This could lead to vector register corruption if a kernel fpu context uses
any of the vector registers 8 to 15 and is interrupted or calls a
KERNEL_FPR context. If that context uses also vector registers 8 to 15,
their contents will be corrupted on return.

Luckily this is currently not a real bug, since the kernel has only one
KERNEL_FPR user with s390_adjust_jiffies() and it is only using floating
point registers 0 to 2.

Fix this by using the correct bits for KERNEL_FPR.

Fixes: 7f79695cc1b6 ("s390/fpu: improve kernel_fpu_[begin|end]")
Signed-off-by: Heiko Carstens 
Reviewed-by: Hendrik Brueckner 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/debug: add _ASM_S390_ prefix to header guard

2023-02-06T06:52:41+00:00

[ Upstream commit 0d4d52361b6c29bf771acd4fa461f06d78fb2fac ]

Using DEBUG_H without a prefix is very generic and inconsistent with
other header guards in arch/s390/include/asm. In fact it collides with
the same name in the ath9k wireless driver though that depends on !S390
via disabled wireless support. Let's just use a consistent header guard
name and prevent possible future trouble.

Signed-off-by: Niklas Schnelle 
Signed-off-by: Heiko Carstens 
Signed-off-by: Sasha Levin

s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple()

2023-01-18T10:42:01+00:00

commit e3f360db08d55a14112bd27454e616a24296a8b0 upstream.

Make sure that *ptr__ within arch_this_cpu_to_op_simple() is only
dereferenced once by using READ_ONCE(). Otherwise the compiler could
generate incorrect code.

Cc: 
Reviewed-by: Alexander Gordeev 
Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

s390/futex: add missing EX_TABLE entry to __futex_atomic_op()

2022-11-03T14:56:54+00:00

commit a262d3ad6a433e4080cecd0a8841104a5906355e upstream.

For some exception types the instruction address points behind the
instruction that caused the exception. Take that into account and add
the missing exception table entry.

Cc: 
Reviewed-by: Vasily Gorbik 
Signed-off-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Greg Kroah-Hartman