linux.git/drivers/s390, branch v5.10.194

scsi: zfcp: Defer fc_rport blocking until after ADISC response

2023-08-11T09:57:51+00:00

commit e65851989001c0c9ba9177564b13b38201c0854c upstream.

Storage devices are free to send RSCNs, e.g. for internal state changes. If
this happens on all connected paths, zfcp risks temporarily losing all
paths at the same time. This has strong requirements on multipath
configuration such as "no_path_retry queue".

Avoid such situations by deferring fc_rport blocking until after the ADISC
response, when any actual state change of the remote port became clear.
The already existing port recovery triggers explicitly block the fc_rport.
The triggers are: on ADISC reject or timeout (typical cable pull case), and
on ADISC indicating that the remote port has changed its WWPN or
the port is meanwhile no longer open.

As a side effect, this also removes a confusing direct function call to
another work item function zfcp_scsi_rport_work() instead of scheduling
that other work item. It was probably done that way to have the rport block
side effect immediate and synchronous to the caller.

Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
Cc: stable@vger.kernel.org #v2.6.30+
Reviewed-by: Benjamin Block 
Reviewed-by: Fedor Loshakov 
Signed-off-by: Steffen Maier 
Link: https://lore.kernel.org/r/20230724145156.3920244-1-maier@linux.ibm.com
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

s390/qeth: Don't call dev_close/dev_open (DOWN/UP)

2023-08-11T09:57:50+00:00

[ Upstream commit 1cfef80d4c2b2c599189f36f36320b205d9447d9 ]

dev_close() and dev_open() are issued to change the interface state to DOWN
or UP (dev->flags IFF_UP). When the netdev is set DOWN it loses e.g its
Ipv6 addresses and routes. We don't want this in cases of device recovery
(triggered by hardware or software) or when the qeth device is set
offline.

Setting a qeth device offline or online and device recovery actions call
netif_device_detach() and/or netif_device_attach(). That will reset or
set the LOWER_UP indication i.e. change the dev->state Bit
__LINK_STATE_PRESENT. That is enough to e.g. cause bond failovers, and
still preserves the interface settings that are handled by the network
stack.

Don't call dev_open() nor dev_close() from the qeth device driver. Let the
network stack handle this.

Fixes: d4560150cb47 ("s390/qeth: call dev_close() during recovery")
Signed-off-by: Alexandra Winter 
Reviewed-by: Wenjia Zhang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

s390/dasd: fix hanging device after quiesce/resume

2023-08-11T09:57:44+00:00

commit 05f1d8ed03f547054efbc4d29bb7991c958ede95 upstream.

Quiesce and resume are functions that tell the DASD driver to stop/resume
issuing I/Os to a specific DASD.

On resume dasd_schedule_block_bh() is called to kick handling of IO
requests again. This does unfortunately not cover internal requests which
are used for path verification for example.

This could lead to a hanging device when a path event or anything else
that triggers internal requests occurs on a quiesced device.

Fix by also calling dasd_schedule_device_bh() which triggers handling of
internal requests on resume.

Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")

Cc: stable@vger.kernel.org
Signed-off-by: Stefan Haberland 
Reviewed-by: Jan Hoeppner 
Link: https://lore.kernel.org/r/20230721193647.3889634-2-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

s390/qeth: Fix vipa deletion

2023-07-27T06:44:10+00:00

[ Upstream commit 80de809bd35e2a8999edf9f5aaa2d8de18921f11 ]

Change boolean parameter of function "qeth_l3_vipa_store" inside the
"qeth_l3_dev_vipa_del4_store" function from "true" to "false" because
"true" is used for adding a virtual ip address and "false" for deleting.

Fixes: 2390166a6b45 ("s390/qeth: clean up L3 sysfs code")

Reviewed-by: Alexandra Winter 
Reviewed-by: Wenjia Zhang 
Signed-off-by: Thorsten Winkler 
Signed-off-by: Alexandra Winter 
Reviewed-by: Simon Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

s390/cio: unregister device when the only path is gone

2023-06-28T08:28:15+00:00

[ Upstream commit 89c0c62e947a01e7a36b54582fd9c9e346170255 ]

Currently, if the device is offline and all the channel paths are
either configured or varied offline, the associated subchannel gets
unregistered. Don't unregister the subchannel, instead unregister
offline device.

Signed-off-by: Vineeth Vijayan 
Reviewed-by: Peter Oberparleiter 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/dasd: Use correct lock while counting channel queue length

2023-06-14T09:09:51+00:00

commit ccc45cb4e7271c74dbb27776ae8f73d84557f5c6 upstream.

The lock around counting the channel queue length in the BIODASDINFO
ioctl was incorrectly changed to the dasd_block->queue_lock with commit
583d6535cb9d ("dasd: remove dead code"). This can lead to endless list
iterations and a subsequent crash.

The queue_lock is supposed to be used only for queue lists belonging to
dasd_block. For dasd_device related queue lists the ccwdev lock must be
used.

Fix the mentioned issues by correctly using the ccwdev lock instead of
the queue lock.

Fixes: 583d6535cb9d ("dasd: remove dead code")
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Jan Höppner 
Reviewed-by: Stefan Haberland 
Signed-off-by: Stefan Haberland 
Link: https://lore.kernel.org/r/20230609153750.1258763-2-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

s390/pkey: zeroize key blobs

2023-06-09T08:30:11+00:00

[ Upstream commit 844cf829e5f33e00b279230470c8c93b58b8c16f ]

Key blobs for the IOCTLs PKEY_KBLOB2PROTK[23] may contain clear key
material. Zeroize the copies of these keys in kernel memory after
creating the protected key.

Reviewed-by: Harald Freudenberger 
Signed-off-by: Holger Dengler 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/qdio: fix do_sqbs() inline assembly constraint

2023-05-30T11:57:55+00:00

[ Upstream commit 2862a2fdfae875888e3c1c3634e3422e01d98147 ]

Use "a" constraint instead of "d" constraint to pass the state parameter to
the do_sqbs() inline assembly. This prevents that general purpose register
zero is used for the state parameter.

If the compiler would select general purpose register zero this would be
problematic for the used instruction in rsy format: the register used for
the state parameter is a base register. If the base register is general
purpose register zero the contents of the register are unexpectedly ignored
when the instruction is executed.

This only applies to z/VM guests using QIOASSIST with dedicated (pass through)
QDIO-based devices such as FCP [zfcp driver] as well as real OSA or
HiperSockets [qeth driver].

A possible symptom for this case using zfcp is the following repeating kernel
message pattern:

zfcp : A QDIO problem occurred
zfcp : A QDIO problem occurred
zfcp : qdio: ZFCP on SC  using AI:1 QEBSM:1 PRI:1 TDD:1 SIGA: W
zfcp : A QDIO problem occurred
zfcp : A QDIO problem occurred

Each of the qdio problem message can be accompanied by the following entries
for the affected subchannel  in
/sys/kernel/debug/s390dbf/qdio_error/hex_ascii for zfcp or qeth:

 ccq: 69....
 SQBS ERROR.

Reviewed-by: Benjamin Block 
Cc: Steffen Maier 
Fixes: 8129ee164267 ("[PATCH] s390: qdio V=V pass-through")
Cc: 
Signed-off-by: Heiko Carstens 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/qdio: get rid of register asm

2023-05-30T11:57:55+00:00

[ Upstream commit d3e2ff5436d6ee38b572ba5c01dc7994769bec54 ]

Reviewed-by: Benjamin Block 
Signed-off-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik 
Stable-dep-of: 2862a2fdfae8 ("s390/qdio: fix do_sqbs() inline assembly constraint")
Signed-off-by: Sasha Levin

s390/dasd: fix hanging blockdevice after request requeue

2023-05-17T09:48:06+00:00

commit d8898ee50edecacdf0141f26fd90acf43d7e9cd7 upstream.

The DASD driver does not kick the requeue list when requeuing IO requests
to the blocklayer. This might lead to hanging blockdevice when there is
no other trigger for this.

Fix by automatically kick the requeue list when requeuing DASD requests
to the blocklayer.

Fixes: e443343e509a ("s390/dasd: blk-mq conversion")
CC: stable@vger.kernel.org # 4.14+
Signed-off-by: Stefan Haberland 
Reviewed-by: Jan Hoeppner 
Reviewed-by: Halil Pasic 
Link: https://lore.kernel.org/r/20230405142017.2446986-8-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman