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:18:07 +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: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.

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ