Re: [PATCH v9 05/11] scsi: scsi_debug: Report the residual of a write

[Niklas Cassel <cassel@kernel.org>]

On Mon, Sep 28, 2026 at 08:45:30AM +0200, Damien Le Moal wrote:
> On 2026/09/27 7:26, Niklas Cassel wrote:
> > A write whose data buffer is larger than its transfer length leaves a
> > residual that the initiator is entitled to be told about. 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.
>
> I am not convinced this is correct. resid (residual count) is supposed to
> indicate the amount of data that was *not* transferred. So if the buffer size is
> larger that the command cdb transfer count, all data can be transferred and
> resid should be 0. Which would mean that for this case, the write processing is
> correct but the read side is not.
>
> The SBC and SPC specs are very silent about this though, I do not think that the
> resid is actually standardized. And I do not see a clear definition for it in
> the documentation/code comments.

The definition is in Documentation/scsi/scsi_mid_low_api.rst,
under resid_len: "an LLD should set this unsigned integer to the requested
transfer length (i.e. 'request_bufflen') less the number of bytes that are
actually transferred".

Also in include/scsi/sg.h: "resid; /* [o] dxfer_len - actual_transferred */".

Both measure it against the buffer, not the CDB.

That is also what iSCSI reports: RFC 7143 11.4.5.1 measures the residual
against the Expected Data Transfer Length, which the initiator sets from the
buffer.

And it is what scsi_debug has always done for reads, in fill_from_dev_buffer().
This patch just does the same for writes.


Let me clarify the commit message in v10 to actually reference
Documentation/scsi/scsi_mid_low_api.rst.


Kind regards,
Niklas