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

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

On 2026/09/28 9:51, Damien Le Moal wrote:
> On 2026/09/28 9:15, Niklas Cassel wrote:
>> 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.
> 
> Hmm. OK. But then that really should be set automatically by the sd/st/sr
> drivers and sg driver. scsi_debug emulates a device, which does not give the
> residual. So scsi_debug has no business setting that command residual at all,
> for any command.

Please ignore this rambling. scsi_debug emulates a scsi host (i.e. an adapter)
with logical units (devices) attached to it. And it is perfectly fine for a host
driver to set the residual. Your patch is fine and I think I need more coffee :)


-- 
Damien Le Moal
Western Digital Research