Re: [PATCH v3 1/6] scsi: scsi_debug: Report the residual of a write

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

On 2026/09/17 19:54, Niklas Cassel wrote:
> 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>

Yes. That goes with my comment about partial writes on v2.

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

-- 
Damien Le Moal
Western Digital Research