linux-stable.git/drivers/s390, branch linux-5.10.y

s390/zcrypt: Enable AUTOSEL_DOM for CCA serialnr sysfs attribute

2026-04-18T08:31:00+00:00

[ Upstream commit 598bbefa8032cc58b564a81d1ad68bd815c8dc0f ]

The serialnr sysfs attribute for CCA cards when queried always
used the default domain for sending the request down to the card.
If for any reason exactly this default domain is disabled then
the attribute code fails to retrieve the CCA info and the sysfs
entry shows an empty string. Works as designed but the serial
number is a card attribute and thus it does not matter which
domain is used for the query. So if there are other domains on
this card available, these could be used.

So extend the code to use AUTOSEL_DOM for the domain value to
address any online domain within the card for querying the cca
info and thus show the serialnr as long as there is one domain
usable regardless of the default domain setting.

Fixes: 8f291ebf3270 ("s390/zcrypt: enable card/domain autoselect on ep11 cprbs")
Suggested-by: Ingo Franzki 
Signed-off-by: Harald Freudenberger 
Reviewed-by: Ingo Franzki 
Cc: stable@vger.kernel.org
Signed-off-by: Vasily Gorbik 
[ preserved zc->online as the fourth argument to cca_get_info() ]
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

s390/cio: Fix device lifecycle handling in css_alloc_subchannel()

2026-03-04T12:19:23+00:00

[ Upstream commit f65c75b0b9b5a390bc3beadcde0a6fbc3ad118f7 ]

`css_alloc_subchannel()` calls `device_initialize()` before setting up
the DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails,
the error path frees the subchannel structure directly, bypassing
the device model reference counting.

Once `device_initialize()` has been called, the embedded struct device
must be released via `put_device()`, allowing the release callback to
free the container structure.

Fix the error path by dropping the initial device reference with
`put_device()` instead of calling `kfree()` directly.

This ensures correct device lifetime handling and avoids potential
use-after-free or double-free issues.

Fixes: e5dcf0025d7af ("s390/css: move subchannel lock allocation")
Signed-off-by: Salah Triki 
Reviewed-by: Vineeth Vijayan 
Signed-off-by: Heiko Carstens 
Signed-off-by: Sasha Levin

s390/ap: Don't leak debug feature files if AP instructions are not available

2026-01-19T12:11:28+00:00

[ Upstream commit 020d5dc57874e58d3ebae398f3fe258f029e3d06 ]

If no AP instructions are available the AP bus module leaks registered
debug feature files. Change function call order to fix this.

Fixes: cccd85bfb7bf ("s390/zcrypt: Rework debug feature invocations.")
Reviewed-by: Harald Freudenberger 
Signed-off-by: Heiko Carstens 
Signed-off-by: Sasha Levin

s390/ctcm: Fix double-kfree

2025-12-06T21:08:20+00:00

[ Upstream commit da02a1824884d6c84c5e5b5ac373b0c9e3288ec2 ]

The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally
from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.
After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'
frees it again.

Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.

Bug detected by the clang static analyzer.

Fixes: 0c0b20587b9f25a2 ("s390/ctcm: fix potential memory leak")
Reviewed-by: Aswin Karuvally 
Signed-off-by: Aleksei Nikiforov 
Signed-off-by: Aswin Karuvally 
Reviewed-by: Simon Horman 
Link: https://patch.msgid.link/20251112182724.1109474-1-aswin@linux.ibm.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

scsi: s390: zfcp: Ensure synchronous unit_add

2025-06-27T10:04:20+00:00

commit 9697ca0d53e3db357be26d2414276143c4a2cd49 upstream.

Improve the usability of the unit_add sysfs attribute by ensuring that
the associated FCP LUN scan processing is completed synchronously.  This
enables configuration tooling to consistently determine the end of the
scan process to allow for serialization of follow-on actions.

While the scan process associated with unit_add typically completes
synchronously, it is deferred to an asynchronous background process if
unit_add is used before initial remote port scanning has completed.  This
occurs when unit_add is used immediately after setting the associated FCP
device online.

To ensure synchronous unit_add processing, wait for remote port scanning
to complete before initiating the FCP LUN scan.

Cc: stable@vger.kernel.org
Reviewed-by: M Nikhil 
Reviewed-by: Nihar Panda 
Signed-off-by: Peter Oberparleiter 
Signed-off-by: Nihar Panda 
Link: https://lore.kernel.org/r/20250603182252.2287285-2-niharp@linux.ibm.com
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

s390/dasd: fix double module refcount decrement

2025-05-02T05:41:09+00:00

commit c3116e62ddeff79cae342147753ce596f01fcf06 upstream.

Once the discipline is associated with the device, deleting the device
takes care of decrementing the module's refcount.  Doing it manually on
this error path causes refcount to artificially decrease on each error
while it should just stay the same.

Fixes: c020d722b110 ("s390/dasd: fix panic during offline processing")
Signed-off-by: Miroslav Franc 
Signed-off-by: Jan Höppner 
Signed-off-by: Stefan Haberland 
Link: https://lore.kernel.org/r/20240209124522.3697827-3-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
[Minor context change fixed]
Signed-off-by: Feng Liu 
Signed-off-by: He Zhe 
Signed-off-by: Greg Kroah-Hartman

s390/cio: Fix CHPID "configure" attribute caching

2025-04-10T12:30:50+00:00

[ Upstream commit 32ae4a2992529e2c7934e422035fad1d9b0f1fb5 ]

In some environments, the SCLP firmware interface used to query a
CHPID's configured state is not supported. On these environments,
rapidly reading the corresponding sysfs attribute produces inconsistent
results:

  $ cat /sys/devices/css0/chp0.00/configure
  cat: /sys/devices/css0/chp0.00/configure: Operation not supported
  $ cat /sys/devices/css0/chp0.00/configure
  3

This occurs for example when Linux is run as a KVM guest. The
inconsistency is a result of CIO using cached results for generating
the value of the "configure" attribute while failing to handle the
situation where no data was returned by SCLP.

Fix this by not updating the cache-expiration timestamp when SCLP
returns no data. With the fix applied, the system response is
consistent:

  $ cat /sys/devices/css0/chp0.00/configure
  cat: /sys/devices/css0/chp0.00/configure: Operation not supported
  $ cat /sys/devices/css0/chp0.00/configure
  cat: /sys/devices/css0/chp0.00/configure: Operation not supported

Reviewed-by: Vineeth Vijayan 
Reviewed-by: Eric Farman 
Tested-by: Eric Farman 
Signed-off-by: Peter Oberparleiter 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Sasha Levin

s390/sclp_vt220: Convert newlines to CRLF instead of LFCR

2024-10-22T13:39:25+00:00

commit dee3df68ab4b00fff6bdf9fc39541729af37307c upstream.

According to the VT220 specification the possible character combinations
sent on RETURN are only CR or CRLF [0].

	The Return key sends either a CR character (0/13) or a CR
	character (0/13) and an LF character (0/10), depending on the
	set/reset state of line feed/new line mode (LNM).

The sclp/vt220 driver however uses LFCR. This can confuse tools, for
example the kunit runner.

Link: https://vt100.net/docs/vt220-rm/chapter3.html#S3.2
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Weißschuh 
Reviewed-by: Sven Schnelle 
Link: https://lore.kernel.org/r/20241014-s390-kunit-v1-2-941defa765a6@linutronix.de
Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

s390/zcore: release dump save area on restart or power down

2024-10-17T13:08:28+00:00

[ Upstream commit dabdfac0e85c8c1e811b10c08742f49285e78a17 ]

The zFCP/NVMe standalone dumper is supposed to release the dump save area
resource as soon as possible but might fail to do so, for instance, if it
crashes. To avoid this situation, register a reboot notifier and ensure
the dump save area resource is released on reboot or power down.

Signed-off-by: Alexander Egorenkov 
Reviewed-by: Heiko Carstens 
Signed-off-by: Heiko Carstens 
Stable-dep-of: 0b18c852cc6f ("tracing: Have saved_cmdlines arrays all in one allocation")
Signed-off-by: Sasha Levin

s390/zcore: no need to check return value of debugfs_create functions

2024-10-17T13:08:28+00:00

[ Upstream commit 7449ca87312a5b0390b765be65a126e6e5451026 ]

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

See commit 7dd541a3fb34 ("s390: no need to check return value of debugfs_create functions").

Signed-off-by: Alexander Egorenkov 
Signed-off-by: Heiko Carstens 
Stable-dep-of: 0b18c852cc6f ("tracing: Have saved_cmdlines arrays all in one allocation")
Signed-off-by: Sasha Levin