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:   Sat, 29 Apr 2017 00:29:28 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        David Ahern <dsa@...ulusnetworks.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        mlxsw@...lanox.com, Simon Horman <simon.horman@...ronome.com>
Subject: Re: [patch net-next 02/10] net: sched: introduce tcf block
 infractructure

Fri, Apr 28, 2017 at 07:48:34PM CEST, xiyou.wangcong@...il.com wrote:
>On Thu, Apr 27, 2017 at 4:12 AM, Jiri Pirko <jiri@...nulli.us> wrote:
>> From: Jiri Pirko <jiri@...lanox.com>
>>
>> Currently, the filter chains are direcly put into the private structures
>> of qdiscs. In order to be able to have multiple chains per qdisc and to
>> allow filter chains sharing among qdiscs, there is a need for common
>> object that would hold the chains. This introduces such object and calls
>> it "tcf_block".
>>
>
>What is filter chains sharing here? Sounds like a new feature you are
>trying to hide? How could it be possibly shared among qdisc's when they
>are still stored in a per-qdisc pointer?

I can change the description. I just found out that eventually, later
on, the blocks could be shared among qdiscs. It is not part of this
patchset. Just this change of infra is bringing this one step closer.

I can imagine that the blocks could have indexes and when you create a
qdisc you could pass this index of an existing block.

Not trying to hide anything!


>
>Look at tc actions, they can be shared because they are physically stored
>in a per-netns hashtable, filters can just refer them with indexes.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ