I'm glad to see that both commits: 5b53a405e465 5b53a405e4658580e1faf7c217db3f55a21ba849 "s390/dasd: fix data corruption for ESE devices" and 71f387165737 71f3871657370dbbaf942a1c758f64e49a36c70f "s390/dasd: prevent double format of tracks for ESE devices" are tagged for stable updates: "Cc: sta...@vger.kernel.org # 5.3+" With that, these commits will automatically be picked up by the Ubuntu kernel teams "Focal update: v5.4.xxx upstream stable release" process.
This hasn't happened yet with the latest ticket: "Focal update: v5.4.191 upstream stable release" - LP#1976116 but will be soon. This LP bug will be used for tracking the status. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1976533 Title: [UBUNTU 20.04] s390/DASD: Fix data corruption for ESE devices Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: New Bug description: Description: s390/dasd: Fix data corruption for ESE devices Symptom: Filesystem errors and data inconsistency. Problem: Wrong tracks are formatted or the same track is formatted twice. 1. For ESE devices we get an error when accessing an unformatted track. The handling of this error will return zero data for read requests and format the track on demand before writing to it. To do this the code needs to distinguish between read and write requests. This is done with data from the blocklayer request. A pointer to the blocklayer request is stored in the CQR. If there is an error on the device an ERP request is built to do error recovery. While the ERP request is mostly a copy of the original CQR the pointer to the blocklayer request is not copied to not accidentally pass it back to the blocklayer without cleanup. This leads to the error that during ESE handling after an ERP request was built it is not possible to determine the IO direction. This leads to the formatting of a track for read requests which might in turn lead to data corruption. 2. When using alias devices a track might be accessed by multiple requests simultaneously and there is a race window that a track gets formatted twice resulting in data loss. Solution: 1. Return the callback data of the original request in case there are ERP requests build on top of it and thus determine the correct IO direction. 2. Prevent the double format by remembering the amount of formatted tracks when starting a request and comparing this number before actually formatting a track on the fly. If the number has changed there is a chance that the current track was finally formatted in between. As a result do not format the track and restart the current IO to check. Reproduction: Prepare an ESE DASD device using dasdfmt and fdasd. Install any filesystem on the prepared partitions and issue regular I/O using dd or any other tool while Alias DASD devices are set online as well. Upstream-ID: 5b53a405e4658580e1faf7c217db3f55a21ba849 71f3871657370dbbaf942a1c758f64e49a36c70f Problem-ID: 198418 Preventive: yes Date: 2022-06-01 Author: hoepp...@linux.ibm.com Component: kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1976533/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
