Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	"Martin K. Petersen" <mkp@kernel.org>
Cc: linux-scsi@vger.kernel.org, Damien Le Moal <dlemoal@kernel.org>,
	John Garry <john.garry@linux.dev>,
	Niklas Cassel <cassel@kernel.org>
Subject: [PATCH v3 1/6] scsi: scsi_debug: Report the residual of a write
Date: Thu, 17 Sep 2026 14:54:47 +0200	[thread overview]
Message-ID: <20260917125445.1376493-9-cassel@kernel.org> (raw)
In-Reply-To: <20260917125445.1376493-8-cassel@kernel.org>

A command transfers the number of logical blocks that it asks for,
bounded by the data buffer that the initiator provided. When the buffer
is larger than that, the bytes beyond are not transferred, and the
difference is a residual that the initiator is entitled to be told
about.

resp_read_dt0() reports it, as does resp_write_tape(), but the write
paths for a disk do not: scsi_get_resid() keeps the zero that
scsi_debug_queuecommand() initialised it with, so a write with an
oversized buffer completes with GOOD status and a residual of zero, as
though the whole buffer had been consumed. A READ of the same length
into the same buffer reports the residual correctly, so the two
directions disagree.

Report it in resp_write_dt0(), resp_write_scat() and
resp_atomic_write().

resp_write_scat() needs a different expression from the other two. Its
data-out buffer holds the parameter list header and the LBA range
descriptors as well as the data, and sg_off walks over all of it, from
the offset at which the data begins to the end of the last range that
was written, so what the command consumed is sg_off and not the number
of bytes that the last range transferred.

Assisted-by: LLM
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/scsi/scsi_debug.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 6941809dfdb7..641dd6f93791 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -5164,6 +5164,8 @@ static int resp_write_dt0(struct scsi_cmnd *scp, struct sdebug_dev_info *devip)
 			    "%s: write: cdb indicated=%u, IO sent=%d bytes\n",
 			    my_name, num * sdebug_sector_size, ret);
 
+	scsi_set_resid(scp, scsi_bufflen(scp) - ret);
+
 	if (unlikely((sdebug_opts & SDEBUG_OPT_RECOV_DIF_DIX) &&
 		     atomic_read(&sdeb_inject_pending))) {
 		if (sdebug_opts & SDEBUG_OPT_RECOVERED_ERR) {
@@ -5352,6 +5354,7 @@ static int resp_write_scat(struct scsi_cmnd *scp,
 		sg_off += num_by;
 		cum_lb += num;
 	}
+	scsi_set_resid(scp, scsi_bufflen(scp) - sg_off);
 	ret = 0;
 err_out_unlock:
 	sdeb_meta_write_unlock(sip);
@@ -6207,6 +6210,8 @@ static int resp_atomic_write(struct scsi_cmnd *scp,
 		return DID_ERROR << 16;
 	if (unlikely(ret != len * sdebug_sector_size))
 		return DID_ERROR << 16;
+
+	scsi_set_resid(scp, scsi_bufflen(scp) - ret);
 	return 0;
 }
 
-- 
2.55.0


  reply	other threads:[~2026-09-17 12:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 12:54 [PATCH v3 0/6] scsi: scsi_debug: fix zoned write validation Niklas Cassel
2026-09-17 12:54 ` Niklas Cassel [this message]
2026-09-17 13:04   ` [PATCH v3 1/6] scsi: scsi_debug: Report the residual of a write sashiko-bot
2026-09-17 13:06   ` Damien Le Moal
2026-09-17 12:54 ` [PATCH v3 2/6] scsi: scsi_debug: Do not write a partial physical block Niklas Cassel
2026-09-17 13:11   ` Damien Le Moal
2026-09-17 13:47     ` Niklas Cassel
2026-09-17 12:54 ` [PATCH v3 3/6] scsi: scsi_debug: Advance the write pointer over the data written Niklas Cassel
2026-09-17 13:13   ` Damien Le Moal
2026-09-17 12:54 ` [PATCH v3 4/6] scsi: scsi_debug: Enforce physical block alignment of zoned writes Niklas Cassel
2026-09-17 13:09   ` sashiko-bot
2026-09-17 12:54 ` [PATCH v3 5/6] scsi: scsi_debug: Map the region written by WRITE ATOMIC (16) Niklas Cassel
2026-09-17 13:12   ` sashiko-bot
2026-09-17 14:01     ` Niklas Cassel
2026-09-17 13:14   ` Damien Le Moal
2026-09-17 12:54 ` [PATCH v3 6/6] scsi: scsi_debug: Validate zone access for " Niklas Cassel
2026-09-17 13:15   ` Damien Le Moal
2026-09-17 13:05 ` [PATCH v3 0/6] scsi: scsi_debug: fix zoned write validation Damien Le Moal

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=20260917125445.1376493-9-cassel@kernel.org \
    --to=cassel@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dlemoal@kernel.org \
    --cc=john.garry@linux.dev \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mkp@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox