Re: [PATCH] scsi: scsi_debug: default to a higher throughput config

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Stale defer_t in sdebug_scsi_cmd causes premature double scsi_done() leading to UAF.
--

commit 92c33bac6eb173f6156f5a3b2daf5604d8994b5b
Author: John Garry <john.garry@linux.dev>

scsi: scsi_debug: default to a higher throughput config

Currently the default config goes not give as high a throughput as some
would like. Give a higher default throughput by modifying the delay,
can_queue, and clustering defaults.

> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index 3346562275f80..f2afe757c4380 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -79,7 +79,7 @@ static const char *sdebug_version_date = "20210520";
>   */
>  #define DEF_ATO 1
>  #define DEF_CDB_LEN 10
> -#define DEF_JDELAY   1		/* if > 0 unit is a jiffy */
> +#define DEF_JDELAY   0		/* if > 0 unit is a jiffy */

[Severity: Critical]
This is a pre-existing issue, but changing the default delay to 0 exposes it
out-of-the-box to all users.

When delay=0, schedule_resp() takes the early completion path without updating
sd_dp->defer_t or sd_dp->cmpl_ts:

drivers/scsi/scsi_debug.c:schedule_resp() {
    ...
respond_in_thread:      /* call back to mid-layer using invocation thread */
        cmnd->result = pfp != NULL ? pfp(cmnd, devip) : 0;
        cmnd->result &= ~SDEG_RES_IMMED_MASK;
        if (cmnd->result == 0 && scsi_result != 0)
                cmnd->result = scsi_result;
        scsi_done(cmnd);
        return 0;
}

Because scsi_cmd_priv(cmd) is not zeroed per-request by the SCSI midlayer,
a reused tag retains its previous defer_t value.

If the previous command on this tag was polled, defer_t is left as
SDEB_DEFER_POLL. Concurrently, if a userspace thread invokes
sdebug_blk_mq_poll_iter(), it iterates over busy tags, sees the stale
SDEB_DEFER_POLL and expired cmpl_ts, and spuriously calls scsi_done(cmd) a
second time:

drivers/scsi/scsi_debug.c:sdebug_blk_mq_poll_iter() {
    ...
        spin_lock_irqsave(&sdsc->lock, flags);
        sd_dp = &sdsc->sd_dp;
        if (sd_dp->defer_t != SDEB_DEFER_POLL) {
                spin_unlock_irqrestore(&sdsc->lock, flags);
                return true;
        }

        if (time < sd_dp->cmpl_ts) {
                spin_unlock_irqrestore(&sdsc->lock, flags);
                return true;
        }
        spin_unlock_irqrestore(&sdsc->lock, flags);
    ...
        scsi_done(cmd); /* callback to mid level */
}

Could this lead to a double scsi_done() and a Use-After-Free in the block
layer when racing with the early completion path?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902092844.1741533-1-john.garry@linux.dev?part=1