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] [day] [month] [year] [list]

Message-ID: <aXA8mVKyRO3Ufm9N@rkannoth-OptiPlex-7090>
Date: Wed, 21 Jan 2026 08:10:25 +0530
From: Ratheesh Kannoth <rkannoth@...vell.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [net] octeontx2-af: Fix error handling

On 2026-01-21 at 05:19:51, Jakub Kicinski (kuba@...nel.org) wrote:
> 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.
>
> > +		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?
ACK.
>
> > +
> > +fail6:
>
> [ ... ]
>
> > +fail1:
> >  	mutex_unlock(&rvu->rsrc_lock);
> >  	return err;
> >  }
> --
> pw-bot: cr