Re: [PATCH v5 07/17] s390/dasd: Add range-based format-track collision detection

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Removal of the `trkcount` snapshot check before its replacement is fully active leaves a window for silent data corruption, breaking bisectability.
--

--- Patch [7]: [PATCH v5 07/17] s390/dasd: Add range-based format-track collision detection ---
commit 758cbeac7b7b1d21b34dd4da47443455ac60838a
Author: Stefan Haberland <sth@linux.ibm.com>
s390/dasd: Add range-based format-track collision detection

This commit replaces the single per-device format_entry slot with an
array of 16 slots to allow multiple in-flight format requests. It also
rewrites the collision detection to use a range-based overlap check
instead of the previous trkcount snapshot mechanism.

(Note: The standard diff-quoting format has been altered to a free-form
summary due to automated recitation restrictions. Original patch code is
not directly quoted.)

[Severity: Critical]
Does removing the trkcount snapshot before the new collision mechanism is
fully active leave a window for silent data corruption?

In dasd_start_IO() (in drivers/s390/block/dasd.c), the snapshot of the
block's trkcount was removed. Subsequently, in test_and_set_format_track()
(in drivers/s390/block/dasd_eckd.c), the check comparing the snapshot against
the current trkcount was replaced by a check for the collision flag on the CQR.

However, the commit message notes that the new detection only becomes active
later in the series when format requests are routed through
dasd_return_cqr_cb(). Currently, the format CQRs are routed elsewhere, meaning
the collision flag is dormant and never populated.

Can this sequence occur and lead to data loss?
If an IO request (Thread B) hits an unformatted track and enters ERP, and
concurrently another IO request (Thread A) formats the track, writes its
data, and completes. Thread B will not realize the track was formatted after
its IO originally started.

Because the trkcount check is completely removed and the collision flag is
still inactive in this intermediate commit, wouldn't Thread B proceed to
format the track again, effectively erasing Thread A's data?

Could this break bisectability by introducing a vulnerability before the full
feature is wired up later in the series?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731153842.1729627-1-sth@linux.ibm.com?part=7