Re: [PATCH] scsi: smartpqi: Handle pqi_alloc_io_request() failure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch adds unreachable NULL pointer checks for `pqi_alloc_io_request()`. Furthermore, if the code were ever reached, it incorrectly returns a SCSI midlayer queuecommand status code (`SCSI_MLQUEUE_HOST_BUSY`) from synchronous internal management functions.
--

--- Patch [1]: [PATCH] scsi: smartpqi: Handle pqi_alloc_io_request() failure ---
commit 1b3d9355dc4c0807df6a24f973784ecb04a972d7
Author: Triet Hoang <triet.hoang.dev@gmail.com>

scsi: smartpqi: Handle pqi_alloc_io_request() failure

Check the return value of pqi_alloc_io_request() before dereferencing
the returned request in pqi_submit_raid_request_synchronous() and
pqi_lun_reset(). Returns SCSI_MLQUEUE_HOST_BUSY when allocation fails.

> diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c
> index 140e8a6addbe3..5c4f9481923a7 100644
> --- a/drivers/scsi/smartpqi/smartpqi_init.c
> +++ b/drivers/scsi/smartpqi/smartpqi_init.c
> @@ -4673,6 +4673,10 @@ static int pqi_submit_raid_request_synchronous(struct pqi_ctrl_info *ctrl_info,
>  	}
>  
>  	io_request = pqi_alloc_io_request(ctrl_info, NULL);
> +	if (!io_request) {
> +		rc = SCSI_MLQUEUE_HOST_BUSY;

[Severity: Medium]
Is this check reachable? Looking at pqi_alloc_io_request(), when the second
argument is NULL, it enters an infinite loop until it successfully claims
an I/O slot:

drivers/scsi/smartpqi/smartpqi_init.c:pqi_alloc_io_request() {
	...
		while (1) {
			io_request = &ctrl_info->io_request_pool[ctrl_info->scsi_ml_can_queue + i];
			if (atomic_inc_return(&io_request->refcount) == 1)
				break;
			atomic_dec(&io_request->refcount);
			i = (i + 1) % PQI_RESERVED_IO_SLOTS;
		}
	...
}

Also, is it appropriate to return SCSI_MLQUEUE_HOST_BUSY here?

This is an internal synchronous routine which normally returns standard negative
errno values (like -ERESTARTSYS or -ENXIO). Returning a positive midlayer
queuecommand status code could lead to unhandled errors or undefined behavior
in the callers if the code were ever reached.

> +		goto out;
> +	}
>  
>  	put_unaligned_le16(io_request->index,
>  		&(((struct pqi_raid_path_request *)request)->request_id));

[ ... ]

> @@ -6370,6 +6374,9 @@ static int pqi_lun_reset(struct pqi_ctrl_info *ctrl_info, struct pqi_scsi_dev *d
>  	struct pqi_task_management_request *request;
>  
>  	io_request = pqi_alloc_io_request(ctrl_info, NULL);
> +	if (!io_request)
> +		return SCSI_MLQUEUE_HOST_BUSY;

[Severity: Medium]
Similarly, is it possible for pqi_alloc_io_request() to return NULL here?
Does returning SCSI_MLQUEUE_HOST_BUSY from this task management caller violate
standard error handling expectations?

> +
>  	io_request->io_complete_callback = pqi_lun_reset_complete;
>  	io_request->context = &wait;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817033505.736519-1-triet.hoang.dev@gmail.com?part=1