Re: [net] octeontx2-af: Fix error handling

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
octeontx2-af: Fix error handling

This commit adds error handling and rollback logic to
rvu_mbox_handler_attach_resources() to properly clean up partially
attached resources when rvu_attach_block() fails.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> index 2d78e08f985f..9b898d718fbf 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c

[ ... ]

> @@ -1724,22 +1725,31 @@ int rvu_mbox_handler_attach_resources(struct rvu *rvu,
>  	int err;
>
>  	/* If first request, detach all existing attached resources */
> -	if (!attach->modify)
> -		rvu_detach_rsrcs(rvu, NULL, pcifunc);
> +	if (!attach->modify) {
> +		err = rvu_detach_rsrcs(rvu, NULL, pcifunc);
> +		if (err)
> +			return err;
> +	}
>
>  	mutex_lock(&rvu->rsrc_lock);

[ ... ]

> +		err = rvu_attach_block(rvu, pcifunc, BLKTYPE_CPT,
> +				       attach->cptlfs, attach);
> +		if (err)
> +			goto fail6;
>  	}
>
> -exit:
> +	return 0;
                ^^^^

The success path returns here without calling mutex_unlock(). The mutex
was acquired earlier via mutex_lock(&rvu->rsrc_lock) but the success
path bypasses the unlock at fail1. Will this cause rvu->rsrc_lock to
remain held after a successful attach, leading to a deadlock on the
next call?

> +
> +fail6:

[ ... ]

> +fail1:
>  	mutex_unlock(&rvu->rsrc_lock);
>  	return err;
>  }
-- 
pw-bot: cr