nfnetlink warnings

Hey,

so I keep getting those since recently:

net/netfilter/nfnetlink_queue.c:519:19: warning: ‘nfnl_ct’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  if (ct && nfnl_ct->build(skb, ct, ctinfo, NFQA_CT, NFQA_CT_INFO) < 0)
                   ^
net/netfilter/nfnetlink_queue.c:316:23: note: ‘nfnl_ct’ was declared here
  struct nfnl_ct_hook *nfnl_ct;
                       ^
net/netfilter/nfnetlink_queue.c: In function ‘nfqnl_recv_verdict’:
net/netfilter/nfnetlink_queue.c:1083:11: warning: ‘nfnl_ct’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    nfnl_ct->seq_adjust(entry->skb, ct, ctinfo, diff);
           ^

and was thinking can we shut them up like this? I know, it is ugly :-\

I mean, it is obvious in both cases that nfnl_ct won't be used if ct is
not set but apparently gcc can't see that far...

---

Hi, Borislav

Why not just initialized it as NULL, or mark it as uninitialized_var()?

Regards,
Michael Wang

On 11/23/2015 10:36 AM, Borislav Petkov wrote:
> Hey,
> 
> so I keep getting those since recently:
> 
> net/netfilter/nfnetlink_queue.c:519:19: warning: ‘nfnl_ct’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>   if (ct && nfnl_ct->build(skb, ct, ctinfo, NFQA_CT, NFQA_CT_INFO) < 0)
>                    ^
> net/netfilter/nfnetlink_queue.c:316:23: note: ‘nfnl_ct’ was declared here
>   struct nfnl_ct_hook *nfnl_ct;
>                        ^
> net/netfilter/nfnetlink_queue.c: In function ‘nfqnl_recv_verdict’:
> net/netfilter/nfnetlink_queue.c:1083:11: warning: ‘nfnl_ct’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>     nfnl_ct->seq_adjust(entry->skb, ct, ctinfo, diff);
>            ^
> 
> and was thinking can we shut them up like this? I know, it is ugly :-\
> 
> I mean, it is obvious in both cases that nfnl_ct won't be used if ct is
> not set but apparently gcc can't see that far...
> 
> ---
> diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
> index 7d81d280cb4f..cd61b0b5c413 100644
> --- a/net/netfilter/nfnetlink_queue.c
> +++ b/net/netfilter/nfnetlink_queue.c
> @@ -372,6 +372,8 @@ nfqnl_build_packet_message(struct net *net, struct nfqnl_instance *queue,
>  			if (ct != NULL)
>  				size += nfnl_ct->build_size(ct);
>  		}
> +	} else {
> +		nfnl_ct = NULL;
>  	}
>  
>  	if (queue->flags & NFQA_CFG_F_UID_GID) {
> @@ -1069,6 +1071,8 @@ nfqnl_recv_verdict(struct sock *ctnl, struct sk_buff *skb,
>  		nfnl_ct = rcu_dereference(nfnl_ct_hook);
>  		if (nfnl_ct != NULL)
>  			ct = nfqnl_ct_parse(nfnl_ct, nlh, nfqa, entry, &ctinfo);
> +	} else {
> +		nfnl_ct = NULL;
>  	}
>  
>  	if (nfqa[NFQA_PAYLOAD]) {
> 
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Michael,

On Mon, Nov 23, 2015 at 10:49:34AM +0100, Michael Wang wrote:
> Why not just initialized it as NULL, or mark it as uninitialized_var()?

because I'd like us to save us the redundant NULL initialization in the
if-case.

I'm not saying any of the approaches are good visually, though. Who
knows, someone might have a better idea like, maybe "Oh, I wanted to
rewrite that code and this handlong is going to be different anyway ..."
or so. Or something to that effect.

Btw, please do not top-post.

Thanks.

On 11/23/2015 10:54 AM, Borislav Petkov wrote:
> Hi Michael,
> 
> On Mon, Nov 23, 2015 at 10:49:34AM +0100, Michael Wang wrote:
>> Why not just initialized it as NULL, or mark it as uninitialized_var()?
> 
> because I'd like us to save us the redundant NULL initialization in the
> if-case.

Well, I would vote initialized with NULL, rather than use another else
branch to do the same thing.

> 
> I'm not saying any of the approaches are good visually, though. Who
> knows, someone might have a better idea like, maybe "Oh, I wanted to
> rewrite that code and this handlong is going to be different anyway ..."
> or so. Or something to that effect.

Who want to do that would take responsibility to make an else branch at
that time, but reserve the branch at this moment sounds unnecessary, and
not that pretty frankly speaking.

> 
> Btw, please do not top-post.

Enjoy ;-)

Regards,
Michael Wang

> 
> Thanks.
> 
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I have just applied this patch to resolve this issue.

http://git.kernel.org/cgit/linux/kernel/git/pablo/nf.git/commit/?id=8e662164abb4a8fde701a46e1431980f9e325742

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Nov 23, 2015 at 11:20:18AM +0100, Michael Wang wrote:
> Who want to do that would take responsibility to make an else branch at
> that time, but reserve the branch at this moment sounds unnecessary, and
> not that pretty frankly speaking.

Actually, I was looking for the better idea which doesn't uglify the
code. And here it is:

https://lkml.kernel.org/r/5585663.OcpAQiytKY@wuerfel

:-)

On 11/23/2015 11:32 AM, Borislav Petkov wrote:
> On Mon, Nov 23, 2015 at 11:20:18AM +0100, Michael Wang wrote:
>> Who want to do that would take responsibility to make an else branch at
>> that time, but reserve the branch at this moment sounds unnecessary, and
>> not that pretty frankly speaking.
> 
> Actually, I was looking for the better idea which doesn't uglify the
> code. And here it is:
> 
> https://lkml.kernel.org/r/5585663.OcpAQiytKY@wuerfel

Looks even better :-)

Regards,
Michael Wang

> 
> :-)
> 
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html