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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 17 Jan 2018 21:45:22 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
        mlxsw@...lanox.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        michael.chan@...adcom.com, ganeshgr@...lsio.com,
        saeedm@...lanox.com, matanb@...lanox.com, leonro@...lanox.com,
        idosch@...lanox.com, jakub.kicinski@...ronome.com,
        simon.horman@...ronome.com, pieter.jansenvanvuuren@...ronome.com,
        john.hurley@...ronome.com, alexander.h.duyck@...el.com,
        ogerlitz@...lanox.com, john.fastabend@...il.com,
        daniel@...earbox.net, dsahern@...il.com
Subject: Re: [patch net-next v11 00/13] net: sched: allow qdiscs to share
 filter block instances

Wed, Jan 17, 2018 at 09:18:07PM CET, jiri@...nulli.us wrote:
>Wed, Jan 17, 2018 at 09:03:38PM CET, davem@...emloft.net wrote:
>>From: David Miller <davem@...emloft.net>
>>Date: Wed, 17 Jan 2018 14:55:35 -0500 (EST)
>>
>>> From: Jiri Pirko <jiri@...nulli.us>
>>> Date: Wed, 17 Jan 2018 11:46:44 +0100
>>> 
>>>> Currently the filters added to qdiscs are independent. So for example if you
>>>> have 2 netdevices and you create ingress qdisc on both and you want to add
>>>> identical filter rules both, you need to add them twice. This patchset
>>>> makes this easier and mainly saves resources allowing to share all filters
>>>> within a qdisc - I call it a "filter block". Also this helps to save
>>>> resources when we do offload to hw for example to expensive TCAM.
>>> 
>>> Series applied, thanks Jiri et al.
>>
>>Jiri, I'm not going to revert because of this, but please give me a follow-up
>>patch which deals with this warning:
>>
>>net/sched/cls_api.c: In function ‘tc_dump_tfilter’:
>>net/sched/cls_api.c:1362:8: warning: ‘parent’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>>   if (!tcf_chain_dump(chain, q, parent, skb, cb,
>>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>         index_start, &index))
>>         ~~~~~~~~~~~~~~~~~~~~
>>
>>It's one of those:
>>
>>	u32 var;
>>
>>	if (condition) {
>>		...
>>		goto out;
>>	} else {
>>		var = whatever;
>>	}
>>	use(var);
>>out:
>>	...
>>
>>situations that GCC can't seem to see properly.
>
>Odd. I don't see this warning with:
>gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)
>
>Although parent is never used in case it is unititialize, I will
>initialize to 0 to make gcc happy.

Kbuild bot also did not warn about this.
Hmm, I wonder, isn't this the case when gcc update fixes the warning so
we don't fix it in kernel?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ