[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240914094244.GG12935@kernel.org>
Date: Sat, 14 Sep 2024 10:42:44 +0100
From: Simon Horman <horms@...nel.org>
To: Su Hui <suhui@...china.com>
Cc: jmaloy@...hat.com, ying.xue@...driver.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
nathan@...nel.org, ndesaulniers@...gle.com, morbo@...gle.com,
justinstitt@...gle.com, tuong.t.lien@...tech.com.au,
netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
kernel-janitors@...r.kernel.org
Subject: Re: [PATCH net-next] net: tipc: avoid possible garbage value
On Thu, Sep 12, 2024 at 07:01:20PM +0800, Su Hui wrote:
> Clang static checker (scan-build) warning:
> net/tipc/bcast.c:305:4:
> The expression is an uninitialized value. The computed value will also
> be garbage [core.uninitialized.Assign]
> 305 | (*cong_link_cnt)++;
> | ^~~~~~~~~~~~~~~~~~
>
> tipc_rcast_xmit() will increase cong_link_cnt's value, but cong_link_cnt
> is uninitialized. Although it won't really cause a problem, it's better
> to fix it.
>
> Fixes: dca4a17d24ee ("tipc: fix potential hanging after b/rcast changing")
> Signed-off-by: Su Hui <suhui@...china.com>
Hi Su Hui,
This looks like a bug fix. If so it should be targeted at net rather than
net-next. If not, the Fixes tag should be dropped, and the commit can be
referenced in the patch description with some other text around:
commit dca4a17d24ee ("tipc: fix potential hanging after b/rcast changing")
> ---
> net/tipc/bcast.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
> index 593846d25214..a3699be6a634 100644
> --- a/net/tipc/bcast.c
> +++ b/net/tipc/bcast.c
> @@ -321,7 +321,7 @@ static int tipc_mcast_send_sync(struct net *net, struct sk_buff *skb,
> struct tipc_msg *hdr, *_hdr;
> struct sk_buff_head tmpq;
> struct sk_buff *_skb;
> - u16 cong_link_cnt;
> + u16 cong_link_cnt = 0;
> int rc = 0;
I think we should preserve reverse xmas tree order - longest like to
shortest - for these local variable declarations.
>
> /* Is a cluster supporting with new capabilities ? */
> --
> 2.30.2
>
>
Powered by blists - more mailing lists