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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: scsi_debug: residual reporting bypassed on error paths in resp_write_scat
--

commit 3c508959885d7806b55921f3734fa6ad6ca1e100
Author: Niklas Cassel <cassel@kernel.org>

scsi: scsi_debug: Report the residual of a write

This commit adds residual reporting for writes in the scsi_debug driver. It
ensures that commands whose data buffer is larger than their transfer length
report the unconsumed portion as a residual, making writes behave consistently
with reads.

> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index b64ae3ad300d8..9220758bb8017 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c

[ ... ]

> @@ -5350,6 +5357,13 @@ static int resp_write_scat(struct scsi_cmnd *scp,
>  		sg_off += num_by;
>  		cum_lb += num;
>  	}
> +	/*
> +	 * sg_off counts what the command asked for, which can exceed the
> +	 * buffer: lbdof is not validated against it, and a range is counted
> +	 * in full even if do_device_access() copied less.
> +	 */
> +	if (scsi_bufflen(scp) > sg_off)
> +		scsi_set_resid(scp, scsi_bufflen(scp) - sg_off);
>  	ret = 0;
>  err_out_unlock:
>  	sdeb_meta_write_unlock(sip);

[Severity: Medium]
Does placing the err_out_unlock label after the residual reporting logic
cause error exits to bypass it?

If a write scattered command processes the first LBA range successfully but
fails on a subsequent range (for example, if the second range exceeds
device capacity and check_device_access_params() fails), the code in
resp_write_scat() jumps directly to err_out_unlock:

		ret = check_device_access_params(scp, lba, num, true);
		if (ret)
			goto err_out_unlock;

This bypasses the new residual reporting logic at the end of the function,
leaving the residual incorrectly at 0 instead of reflecting the unwritten
data. Should the residual also be updated before returning from these error
paths?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926181702.508975-13-cassel@kernel.org?part=5