2015-11-23 09:36:17

by Borislav Petkov

[permalink] [raw]
Subject: 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...

---
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]) {

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.


2015-11-23 09:49:38

by Michael Wang

[permalink] [raw]
Subject: Re: nfnetlink warnings

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]) {
>

2015-11-23 09:55:06

by Borislav Petkov

[permalink] [raw]
Subject: Re: nfnetlink warnings

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.

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

2015-11-23 10:20:47

by Michael Wang

[permalink] [raw]
Subject: Re: nfnetlink warnings



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.
>

2015-11-23 10:32:21

by Borislav Petkov

[permalink] [raw]
Subject: Re: nfnetlink warnings

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

:-)

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

2015-11-23 10:36:41

by Michael Wang

[permalink] [raw]
Subject: Re: nfnetlink warnings



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

>
> :-)
>