Re: [PATCH v10 06/12] scsi: scsi_debug: Report the residual of a write

[Damien Le Moal <dlemoal@kernel.org>]

On 2026/09/28 9:21, Niklas Cassel wrote:
> Documentation/scsi/scsi_mid_low_api.rst defines the residual as the
> length of the data buffer less the number of bytes actually transferred,
> so a write whose data buffer is larger than its transfer length leaves
> one. resp_read_dt0() and resp_write_tape() report it, but the write
> paths for a disk do not, so such a write completes with GOOD status and
> a residual of zero while a READ of the same length into the same buffer
> reports it correctly.
> 
> Report it in resp_write_dt0(), resp_write_scat() and resp_atomic_write().
> 
> resp_write_scat() differs twice over. Its data-out buffer also holds the
> parameter list header and the LBA range descriptors, so what the command
> consumed is sg_off rather than the bytes that the last range
> transferred; and sg_off counts what was asked for rather than what was
> transferred, so it can exceed the buffer and needs a guard. A command
> with no LBA range descriptors or a buffer transfer length of zero
> transfers nothing, so the whole buffer is residual. An error, real or
> injected, can end the command after some ranges have been written, so
> the residual is reported on every exit once the parameter list has been
> fetched.
> 
> Assisted-by: LLM
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
> Tested with:
> 
>   modprobe scsi_debug zbc=managed sector_size=512 physblk_exp=3 \
>       zone_size_mb=8 dev_size_mb=128 zone_nr_conv=2
> 
> An eight logical block WRITE(16) with a 5000 byte buffer reports
> resid=904, having transferred 4096. A READ(16) of the same length into
> the same buffer reported that before this patch and the WRITE reported
> 0. A buffer of exactly 4096 bytes reports 0, as does a 512 byte buffer,
> which is consumed in its entirety. WRITE ATOMIC (16) behaves like the
> WRITE, on a device that is not zoned.
> 
> WRITE SCATTERED (16) with one LBA range descriptor of eight blocks and a
> 5632 byte buffer reports resid=1024, having consumed 512 bytes of
> parameter list and 4096 bytes of data. The same command with a 1024 byte
> buffer completes and reports resid=0: sg_off reaches 4608, past the end
> of the buffer, and without the guard the residual would have been
> reported as 4294963712.
> 
> Changes since v9: the commit message cites the definition of the
> residual in Documentation/scsi/scsi_mid_low_api.rst.
> ---
>  drivers/scsi/scsi_debug.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index 8f9d54269dce..691a5ad56161 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -5162,6 +5162,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);

May be do this under a if:

	if (ret < scsi_bufflen(scp))
		scsi_set_resid(scp, scsi_bufflen(scp) - ret);

> @@ -6208,6 +6221,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);

And here too.

>  	return 0;
>  }

With that,

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>


-- 
Damien Le Moal
Western Digital Research