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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260120234951.1888325-1-kuba@kernel.org>
Date: Tue, 20 Jan 2026 15:49:51 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: rkannoth@...vell.com
Cc: Jakub Kicinski <kuba@...nel.org>,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [net] octeontx2-af: Fix error handling

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