Re: [PATCH v4 08/10] mpi3mr: Fix SAS port allocation and registration error handling

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Skipping `sas_port_delete` and `sas_port_delete_phy` during a controller reset causes permanent memory leaks of SAS transport objects and triggers a kernel `BUG()` on subsequent device discovery.
--

--- Patch [8]: [PATCH v4 08/10] mpi3mr: Fix SAS port allocation and registration error handling ---
commit 2a61369a5f802bef404aa18e7c7a2583f37c4fc7
Author: Ranjan Kumar <ranjan.kumar@broadcom.com>

mpi3mr: Fix SAS port allocation and registration error handling

This commit adds NULL checks after SAS port and rphy allocations to prevent
NULL pointer dereferences. It cleans up memory and state if registration
fails, resolving memory leaks and dangling pointers. Finally, it prevents
deadlocks in the SCSI mid-layer by checking for resets or driver stops.

> diff --git a/drivers/scsi/mpi3mr/mpi3mr_transport.c b/drivers/scsi/mpi3mr/mpi3mr_transport.c
> index b309cfdf66873..db9cb0b03b9ff 100644
> --- a/drivers/scsi/mpi3mr/mpi3mr_transport.c
> +++ b/drivers/scsi/mpi3mr/mpi3mr_transport.c
[ ... ]
> @@ -1600,12 +1644,12 @@ static void mpi3mr_sas_port_remove(struct mpi3mr_ioc *mrioc, u64 sas_address,
>  			    mr_sas_port->remote_identify.sas_address,
>  			    mr_sas_phy->phy_id);
>  		mr_sas_phy->phy_belongs_to_port = 0;
> -		if (!mrioc->stop_drv_processing)
> +		if (!mrioc->stop_drv_processing && !mrioc->reset_in_progress)
>  			sas_port_delete_phy(mr_sas_port->port,
>  			    mr_sas_phy->phy);
>  		list_del(&mr_sas_phy->port_siblings);
>  	}
> -	if (!mrioc->stop_drv_processing)
> +	if (!mrioc->stop_drv_processing && !mrioc->reset_in_progress)
>  		sas_port_delete(mr_sas_port->port);

[Severity: Critical]
Does skipping sas_port_delete() and sas_port_delete_phy() during a reset cause
a memory leak and a kernel BUG() during rediscovery?

Because mr_sas_port is unconditionally freed at the end of
mpi3mr_sas_port_remove(), the transport objects (sas_port and sas_rphy) are
leaked when their delete functions are bypassed.

Additionally, the sas_phy remains linked to the leaked port's phy_list. When
the reset completes and the device comes back online, mpi3mr_sas_port_add()
will create a new port and call sas_port_add_phy() on the same sas_phy.

The SAS transport layer detects the phy is already linked to another port and
intentionally triggers a BUG().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805110634.346670-1-ranjan.kumar@broadcom.com?part=8