[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFVCoxgAnfH1aQ4x@48c69cc54dda>
Date: Fri, 20 Jun 2025 11:14:43 +0000
From: Subbaraya Sundeep <sbhatta@...vell.com>
To: Simon Horman <horms@...nel.org>
CC: <andrew+netdev@...n.ch>, <davem@...emloft.net>, <edumazet@...gle.com>,
<kuba@...nel.org>, <pabeni@...hat.com>, <sgoutham@...vell.com>,
<lcherian@...vell.com>, <gakula@...vell.com>, <jerinj@...vell.com>,
<hkelam@...vell.com>, <saikrishnag@...vell.com>,
<netdev@...r.kernel.org>
Subject: Re: [net-next PATCH] octeontx2-af: Fix rvu_mbox_init return path
On 2025-06-18 at 19:43:01, Simon Horman (horms@...nel.org) wrote:
> On Wed, Jun 18, 2025 at 07:27:16PM +0530, Subbaraya Sundeep wrote:
> > rvu_mbox_init function makes use of error path for
> > freeing memory which are local to the function in
> > both success and failure conditions. This is unusual hence
> > fix it by returning zero on success. With new cn20k code this
> > is freeing valid memory in success case also.
> >
> > Fixes: e53ee4acb220 ("octeontx2-af: CN20k basic mbox operations and structures")
> > Signed-off-by: Subbaraya Sundeep <sbhatta@...vell.com>
>
> Reviewed-by: Simon Horman <horms@...nel.org>
>
> Although I don't think the problem is introduced by this patch
> with it applied Smatch notices that the following code, around line 2528,
> which jumps to free_regions does so with err uninitialised. This is a
> problem because the jump will result in the function returning err.
Thanks Simon for review. I will send fix for Smatch error in
separate patch later.
Sundeep
>
> switch (type) {
> case TYPE_AFPF
> ...
> default:
>
> goto free_regions;
> }
>
> ...
Powered by blists - more mailing lists