Re: [PATCH 1/2] scsi: fix typos in comments

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Double completion and use-after-free race between normal I/O completion and abort timeout.
--

commit 557225524672ba2157c18527e3000f5d88170125
Author: Hemanth Selam <hemanth.selam@gmail.com>
Subject: scsi: fix typos in comments

Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt.  Only touches comments, no code
changes.

> diff --git a/drivers/scsi/csiostor/csio_scsi.c b/drivers/scsi/csiostor/csio_scsi.c
> index 0114e70e98844..ff924be3ecbb9 100644
> --- a/drivers/scsi/csiostor/csio_scsi.c
> +++ b/drivers/scsi/csiostor/csio_scsi.c
[ ... ]
> @@ -1968,7 +1968,7 @@ csio_eh_abort_handler(struct scsi_cmnd *cmnd)
>  
>  	wait_for_completion_timeout(&ioreq->cmplobj, msecs_to_jiffies(tmo));
>  
> -	/* FW didnt respond to abort within our timeout */
> +	/* FW didn't respond to abort within our timeout */
>  	if (((struct scsi_cmnd *)csio_scsi_cmnd(ioreq)) == cmnd) {

[Severity: High]
This is a pre-existing issue, but it appears there might be a race condition
between normal io completion and the abort timeout here.

Looking at csio_eh_abort_handler() in drivers/scsi/csiostor/csio_scsi.c around
line 1968, the driver waits for an abort response via
wait_for_completion_timeout(). If this times out, it locklessly checks if
csio_scsi_cmnd(ioreq) == cmnd.

Concurrently, if the firmware completes the original io, the interrupt
handler calls csio_scsi_err_handler(), which unmaps the dma and completes the
command:

drivers/scsi/csiostor/csio_scsi.c:csio_scsi_err_handler() {
        ...
        scsi_done(cmnd);

        /* Wake up waiting threads */
        csio_scsi_cmnd(req) = NULL;
        complete(&req->cmplobj);
}

If the abort handler's lockless read occurs between the scsi_done(cmnd) call
and the pointer assignment csio_scsi_cmnd(req) = NULL, could it mistakenly
observe that the command has not been completed yet?

This sequence would cause csio_eh_abort_handler() to proceed into its timeout
recovery path and execute a second completion on the potentially already freed
command.

>  
>  		csio_err(hw, "Abort timed out -- req: %p\n", ioreq);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904121449.24178-1-hemanth.selam@gmail.com?part=1