From: sashiko-bot@kernel.org
To: "Stefan Haberland" <sth@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH v7 02/19] s390/dasd: Propagate partial completion length across ERP recovery
Date: Sat, 01 Aug 2026 18:21:52 +0000 [thread overview]
Message-ID: <20260801182153.362F61F00AC4@smtp.kernel.org> (raw)
In-Reply-To: <20260801180033.3679412-3-sth@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] dasd_eckd_ese_read() directly dereferences cqr->callback_data, which is NULL for ERP requests, causing a kernel panic.
--
--- Patch [2]: [PATCH v7 02/19] s390/dasd: Propagate partial completion length across ERP recovery ---
commit 5cfd110150006620d9ee9acaf83c89fea865281b
Author: Stefan Haberland <sth@linux.ibm.com>
s390/dasd: Propagate partial completion length across ERP recovery
This commit ensures that the partial completion length of a request is properly
carried over during error recovery procedure (ERP) post-actions. It addresses
an issue where partially completed requests would silently return zeroed data
because the processed bytes counter was dropped.
> dasd_default_erp_postaction() copies the timing and device state from
> the finished ERP request back to the original request but drops
> proc_bytes. A request that was partially completed, an ESE read of a
> not-yet-allocated track returns fewer bytes than requested, and then
> recovered through the ERP chain loses its partial-completion length.
[Severity: Critical]
This is a pre-existing issue, but since we are looking at ESE reads recovered
through the ERP chain, does the current error handling sequence lead to a NULL
pointer dereference?
When an ERP request encounters a No Record Found (NRF) error while reading
from an unallocated track, dasd_int_handler() processes it. While it uses
dasd_get_callback_data() to check the data direction, it appears to pass the
raw ERP request to ese_read():
drivers/s390/block/dasd.c:dasd_int_handler() {
...
if (device->discipline->ese_read(cqr, irb))
...
}
Inside dasd_eckd_ese_read(), the code directly casts cqr->callback_data
instead of using the helper:
drivers/s390/block/dasd_eckd.c:dasd_eckd_ese_read() {
...
req = (struct request *) cqr->callback_data;
...
first_trk = first_blk = blk_rq_pos(req) >> block->s2b_shift;
...
}
Since ERP requests allocated via dasd_alloc_erp_request() do not set
callback_data, req becomes NULL and is immediately dereferenced by
blk_rq_pos(). Could this cause a kernel panic, and should dasd_eckd_ese_read()
be updated to use dasd_get_callback_data(cqr) instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260801180033.3679412-1-sth@linux.ibm.com?part=2
next prev parent reply other threads:[~2026-08-01 18:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 18:00 [PATCH v7 00/19] s390/dasd: ESE thin-provisioning performance improvements Stefan Haberland
2026-08-01 18:00 ` [PATCH v7 01/19] s390/dasd: Do not complete a failed ESE read as successful Stefan Haberland
2026-08-01 18:30 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 02/19] s390/dasd: Propagate partial completion length across ERP recovery Stefan Haberland
2026-08-01 18:21 ` sashiko-bot [this message]
2026-08-01 18:00 ` [PATCH v7 03/19] s390/dasd: Guard sysfs discipline callbacks against unallocated private data Stefan Haberland
2026-08-01 18:29 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 04/19] s390/dasd: Snapshot intrc before freeing the request block Stefan Haberland
2026-08-01 18:18 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 05/19] s390/dasd: Optimize max blocks per request for track alignment Stefan Haberland
2026-08-01 18:05 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 06/19] s390/dasd: Use GFP_KERNEL in dasd_alloc_device() Stefan Haberland
2026-08-01 18:15 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 07/19] s390/dasd: Add defines for the Extended Address Volume track address Stefan Haberland
2026-08-01 18:05 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 08/19] s390/dasd: Add infrastructure for ESE full-track write Stefan Haberland
2026-08-01 18:21 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 09/19] s390/dasd: Add range-based format-track collision detection Stefan Haberland
2026-08-01 18:23 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 10/19] s390/dasd: Extend prepare_itcw() to support WRITE_FULL_TRACK Stefan Haberland
2026-08-01 18:28 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 11/19] s390/dasd: Add dasd_eckd_build_cp_tpm_writefulltrack() Stefan Haberland
2026-08-01 18:17 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 12/19] s390/dasd: Use WRITE_FULL_TRACK in ESE format handler Stefan Haberland
2026-08-01 18:33 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 13/19] s390/dasd: Add full_track_bias to control fulltrack write mode Stefan Haberland
2026-08-01 18:20 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 14/19] s390/dasd: Derive adaptive ESE fulltrack heuristic from ft_bias Stefan Haberland
2026-08-01 18:17 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 15/19] s390/dasd: Stamp a format label into newly formatted volumes Stefan Haberland
2026-08-01 18:26 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 16/19] s390/dasd: Detect ESE volumes from the on-disk format label Stefan Haberland
2026-08-01 18:39 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 17/19] s390/dasd: Report ESE capability and format mode at device online Stefan Haberland
2026-08-01 18:22 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 18/19] s390/dasd: Re-enable discard support for ESE volumes Stefan Haberland
2026-08-01 18:46 ` sashiko-bot
2026-08-01 18:00 ` [PATCH v7 19/19] s390/dasd: Read cached unit address and LSS in the CCW build path Stefan Haberland
2026-08-01 18:50 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260801182153.362F61F00AC4@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sth@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.