kernel/linux.git/drivers/s390/block, branch v5.15.208

s390/dasd: fix error recovery leading to data corruption on ESE devices

2024-09-04T11:23:15+00:00

commit 7db4042336580dfd75cb5faa82c12cd51098c90b upstream. Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case. Cc: stable@vger.kernel.org # 5.3+ Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes") Reviewed-by: Jan Hoeppner Signed-off-by: Stefan Haberland Link: https://lore.kernel.org/r/20240812125733.126431-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

s390/dasd: fix double module refcount decrement

2024-03-26T22:21:14+00:00

[ Upstream commit c3116e62ddeff79cae342147753ce596f01fcf06 ] 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 Signed-off-by: Sasha Levin

s390/dasd: Use dev_*() for device log messages

2024-03-26T22:21:14+00:00

[ Upstream commit 79ae56fc475869d636071f66d9e4ef2a3819eee6 ] All log messages in dasd.c use the printk variants of pr_*(). They all add the name of the affected device manually to the log message. This can be simplified by using the dev_*() variants of printk, which include the device information and make a separate call to dev_name() unnecessary. The KMSG_COMPONENT and the pr_fmt() definition can be dropped. Note that this removes the "dasd: " prefix from the one pr_info() call in dasd_init(). However, the log message already provides all relevant information. Signed-off-by: Jan Höppner Reviewed-by: Stefan Haberland Signed-off-by: Stefan Haberland Link: https://lore.kernel.org/r/20240208164248.540985-10-sth@linux.ibm.com Signed-off-by: Jens Axboe Stable-dep-of: c3116e62ddef ("s390/dasd: fix double module refcount decrement") Signed-off-by: Sasha Levin

s390/dasd: add autoquiesce feature

2024-03-26T22:21:14+00:00

[ Upstream commit 1cee2975bbabd89df1097c354867192106b058ea ] Add the internal logic to check for autoquiesce triggers and handle them. Quiesce and resume are functions that tell Linux to stop/resume issuing I/Os to a specific DASD. The DASD driver allows a manual quiesce/resume via ioctl. Autoquiesce will define an amount of triggers that will lead to an automatic quiesce if a certain event occurs. There is no automatic resume. All events will be reported via DASD Extended Error Reporting (EER) if configured. Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Reviewed-by: Halil Pasic Link: https://lore.kernel.org/r/20230405142017.2446986-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Stable-dep-of: c3116e62ddef ("s390/dasd: fix double module refcount decrement") Signed-off-by: Sasha Levin

s390/dasd: add copy pair setup

2024-03-26T22:21:14+00:00

[ Upstream commit a91ff09d39f9b6545254839ac91f1ff7bd21d39e ] A copy relation that is configured on the storage server side needs to be enabled separately in the device driver. A sysfs interface is created that allows userspace tooling to control such setup. The following sysfs entries are added to store and read copy relation information: copy_pair - Add/Delete a copy pair relation to the DASD device driver - Query all previously added copy pair relations copy_role - Query the copy pair role of the device To add a copy pair to the DASD device driver it has to be specified through the sysfs attribute copy_pair. Only one secondary device can be specified at a time together with the primary device. Both, secondary and primary can be used equally to define the copy pair. The secondary devices have to be offline when adding the copy relation. The primary device needs to be specified first followed by the comma separated secondary device. Read from the copy_pair attribute to get the current setup and write "clear" to the attribute to delete any existing setup. Example: $ echo 0.0.9700,0.0.9740 > /sys/bus/ccw/devices/0.0.9700/copy_pair $ cat /sys/bus/ccw/devices/0.0.9700/copy_pair 0.0.9700,0.0.9740 During device online processing the required data will be read from the storage server and the information will be compared to the setup requested through the copy_pair attribute. The registration of the primary and secondary device will be handled accordingly. A blockdevice is only allocated for copy relation primary devices. To query the copy role of a device read from the copy_role sysfs attribute. Possible values are primary, secondary, and none. Example: $ cat /sys/bus/ccw/devices/0.0.9700/copy_role primary Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Link: https://lore.kernel.org/r/20220920192616.808070-4-sth@linux.ibm.com Signed-off-by: Jens Axboe Stable-dep-of: c3116e62ddef ("s390/dasd: fix double module refcount decrement") Signed-off-by: Sasha Levin

s390/dasd: add query PPRC function

2024-03-26T22:21:14+00:00

[ Upstream commit 3f217cceb6846e7533511fc69bc774cdba37ff7d ] Add function to query the Peer-to-Peer-Remote-Copy (PPRC) state of a device by reading the related structure through a read subsystem data call. Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Link: https://lore.kernel.org/r/20220920192616.808070-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Stable-dep-of: c3116e62ddef ("s390/dasd: fix double module refcount decrement") Signed-off-by: Sasha Levin

s390/dasd: put block allocation in separate function

2024-03-26T22:21:14+00:00

[ Upstream commit 2b43bf061b2e1b67561cbb1f6f305421f5fc86af ] Put block allocation into a separate function to put some copy pair logic in it in a later patch. Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Link: https://lore.kernel.org/r/20220920192616.808070-2-sth@linux.ibm.com Signed-off-by: Jens Axboe Stable-dep-of: c3116e62ddef ("s390/dasd: fix double module refcount decrement") Signed-off-by: Sasha Levin

s390/scm: fix virtual vs physical address confusion

2024-01-25T22:52:30+00:00

[ Upstream commit b1a6a1a77f0666a5a6dc0893ab6ec8fcae46f24c ] Fix virtual vs physical address confusion (which currently are the same). Signed-off-by: Vineeth Vijayan Reviewed-by: Peter Oberparleiter Acked-by: Alexander Gordeev Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

s390/dasd: protect device queue against concurrent access

2023-12-03T06:31:24+00:00

commit db46cd1e0426f52999d50fa72cfa97fa39952885 upstream. In dasd_profile_start() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasd_profile_start() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses. Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path. Cc: Fixes: 4fa52aa7a82f ("[S390] dasd: add enhanced DASD statistics interface") Reviewed-by: Stefan Haberland Signed-off-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://lore.kernel.org/r/20231025132437.1223363-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

s390/dasd: fix hanging device after request requeue

2023-09-19T10:22:27+00:00

[ Upstream commit 8a2278ce9c25048d999fe1a3561def75d963f471 ] The DASD device driver has a function to requeue requests to the blocklayer. This function is used in various cases when basic settings for the device have to be changed like High Performance Ficon related parameters or copy pair settings. The functions iterates over the device->ccw_queue and also removes the requests from the block->ccw_queue. In case the device is started on an alias device instead of the base device it might be removed from the block->ccw_queue without having it canceled properly before. This might lead to a hanging device since the request is no longer on a queue and can not be handled properly. Fix by iterating over the block->ccw_queue instead of the device->ccw_queue. This will take care of all blocklayer related requests and handle them on all associated DASD devices. Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Link: https://lore.kernel.org/r/20230721193647.3889634-4-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin