From: sashiko-bot@kernel.org
To: "Stefan Haberland" <sth@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH 13/19] s390/dasd: Add full_track_bias to control fulltrack write mode
Date: Wed, 05 Aug 2026 16:41:15 +0000 [thread overview]
Message-ID: <20260805164116.8796E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805111612.1285190-14-sth@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Using `rq_data_dir(req) == WRITE` to gate data buffer accesses allows payload-less requests (such as DISCARD or WRITE_ZEROES) to bypass type safety, leading to a potential NULL pointer dereference.
- [Medium] Inconsistent initialization of `fulltrack` between the module parameter logic and the sysfs store function, leading to divergent behavior for the exact same configuration value.
- [Medium] Concurrent sysfs writes to `full_track_bias` can leave `ft_bias` and `fulltrack` in a permanently inconsistent state.
--
--- Patch [13]: [PATCH 13/19] s390/dasd: Add full_track_bias to control fulltrack write mode ---
commit d2feac141aaa53ff2a5f42b4d0748a881207c899
Author: Stefan Haberland <sth@linux.ibm.com>
s390/dasd: Add full_track_bias to control fulltrack write mode
This patch introduces a per-device full_track_bias sysfs attribute to control
the full-track write path for DASD ECKD devices. It routes aligned full-track
writes through a new function based on the bias value. The patch also adds a
module parameter to set the default bias for all devices at online time.
> diff --git a/drivers/s390/block/dasd_devmap.c b/drivers/s390/block/dasd_devmap.c
> index 381d616ad433f..035c022255b68 100644
> --- a/drivers/s390/block/dasd_devmap.c
> +++ b/drivers/s390/block/dasd_devmap.c
[ ... ]
> @@ -1630,6 +1630,44 @@ dasd_expires_store(struct device *dev, struct device_attribute *attr,
[ ... ]
> +static ssize_t full_track_bias_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct dasd_device *device;
> + unsigned int val;
> +
> + if (kstrtouint(buf, 0, &val) || val > DASD_FT_BIAS_MAX)
> + return -EINVAL;
> +
> + device = dasd_device_from_cdev(to_ccwdev(dev));
> + if (IS_ERR(device))
> + return -ENODEV;
> +
> + device->ft_bias = val;
> + device->fulltrack = val ? 1 : 0;
[Severity: Medium]
Can concurrent sysfs writes to full_track_bias leave ft_bias and fulltrack
in a permanently inconsistent state?
If CPU1 writes 100 and CPU2 writes 0 at the same time, could they interleave
their updates to these two fields, leaving ft_bias at 0 and fulltrack at 1,
or vice-versa?
[Severity: Medium]
Does the logic here mismatch how fulltrack is initialized during online time?
In dasd_eckd_check_characteristics(), fulltrack is set to 1 only when the
bias is >= DASD_FT_BIAS_MAX (100). However, in this sysfs store function,
fulltrack is set to 1 for any non-zero value. Should these conditions match
to prevent the exact same configuration value from producing different
behaviors?
> +
> + dasd_put_device(device);
> + return count;
> +}
[ ... ]
> diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c
> index da488c0775fcd..067ab66209b65 100644
> --- a/drivers/s390/block/dasd_eckd.c
> +++ b/drivers/s390/block/dasd_eckd.c
[ ... ]
> @@ -5204,11 +5221,20 @@ static struct dasd_ccw_req *dasd_eckd_build_cp(struct dasd_device *startdev,
> /* do nothing, just fall through to the cmd mode single case */
> } else if ((data_size <= private->fcx_max_data)
> && (fcx_multitrack || (first_trk == last_trk))) {
> - cqr = dasd_eckd_build_cp_tpm_track(startdev, block, req,
> - first_rec, last_rec,
> - first_trk, last_trk,
> - first_offs, last_offs,
> - blk_per_trk, blksize);
> + if (!first_offs && (last_offs + 1 == blk_per_trk) &&
> + rq_data_dir(req) == WRITE && basedev->fulltrack) {
[Severity: High]
Can payload-less requests (such as DISCARD or WRITE_ZEROES) bypass type
safety here?
The rq_data_dir() check relies on op_is_write(), which returns true for
dataless operations. If dasd_eckd_build_cp_tpm_writefulltrack() then iterates
over the bio segments without verifying bio_has_data(), could this cause a
NULL pointer dereference when accessing the data fields?
> + cqr = dasd_eckd_build_cp_tpm_writefulltrack(startdev, block, req,
> + first_rec, last_rec,
> + first_trk, last_trk,
> + first_offs, last_offs,
> + blk_per_trk, blksize, NULL);
> + } else {
> + cqr = dasd_eckd_build_cp_tpm_track(startdev, block, req,
> + first_rec, last_rec,
> + first_trk, last_trk,
> + first_offs, last_offs,
> + blk_per_trk, blksize);
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260805111612.1285190-1-sth@linux.ibm.com?part=13
next prev parent reply other threads:[~2026-08-05 16:41 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 11:15 [PATCH 00/19] s390/dasd: ESE Performance improvements Stefan Haberland
2026-08-05 11:15 ` [PATCH 01/19] s390/dasd: Do not complete a failed ESE read as successful Stefan Haberland
2026-08-05 11:48 ` sashiko-bot
2026-08-05 11:15 ` [PATCH 02/19] s390/dasd: Propagate partial completion length across ERP recovery Stefan Haberland
2026-08-05 12:17 ` sashiko-bot
2026-08-05 11:15 ` [PATCH 03/19] s390/dasd: Guard sysfs discipline callbacks against unallocated private data Stefan Haberland
2026-08-05 12:44 ` sashiko-bot
2026-08-05 11:15 ` [PATCH 04/19] s390/dasd: Snapshot intrc before freeing the request block Stefan Haberland
2026-08-05 13:06 ` sashiko-bot
2026-08-05 11:15 ` [PATCH 05/19] s390/dasd: Optimize max blocks per request for track alignment Stefan Haberland
2026-08-05 13:10 ` sashiko-bot
2026-08-05 11:15 ` [PATCH 06/19] s390/dasd: Use GFP_KERNEL in dasd_alloc_device() Stefan Haberland
2026-08-05 13:17 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 07/19] s390/dasd: Add defines for the Extended Address Volume track address Stefan Haberland
2026-08-05 13:19 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 08/19] s390/dasd: Add infrastructure for ESE full-track write Stefan Haberland
2026-08-05 14:02 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 09/19] s390/dasd: Add range-based format-track collision detection Stefan Haberland
2026-08-05 15:11 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 10/19] s390/dasd: Extend prepare_itcw() to support WRITE_FULL_TRACK Stefan Haberland
2026-08-05 15:39 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 11/19] s390/dasd: Add dasd_eckd_build_cp_tpm_writefulltrack() Stefan Haberland
2026-08-05 15:53 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 12/19] s390/dasd: Use WRITE_FULL_TRACK in ESE format handler Stefan Haberland
2026-08-05 16:21 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 13/19] s390/dasd: Add full_track_bias to control fulltrack write mode Stefan Haberland
2026-08-05 16:41 ` sashiko-bot [this message]
2026-08-05 11:16 ` [PATCH 14/19] s390/dasd: Derive adaptive ESE fulltrack heuristic from ft_bias Stefan Haberland
2026-08-05 16:48 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 15/19] s390/dasd: Stamp a format label into newly formatted volumes Stefan Haberland
2026-08-05 17:14 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 16/19] s390/dasd: Detect ESE volumes from the on-disk format label Stefan Haberland
2026-08-05 19:34 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 17/19] s390/dasd: Report ESE capability and format mode at device online Stefan Haberland
2026-08-05 19:44 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 18/19] s390/dasd: Re-enable discard support for ESE volumes Stefan Haberland
2026-08-05 20:04 ` sashiko-bot
2026-08-05 11:16 ` [PATCH 19/19] s390/dasd: Read cached unit address and LSS in the CCW build path Stefan Haberland
2026-08-05 20:31 ` sashiko-bot
2026-08-05 12:32 ` [PATCH 00/19] s390/dasd: ESE Performance improvements Jens Axboe
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=20260805164116.8796E1F000E9@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.