netdev - Re: [patch net-next v7 09/13] net: sched: allow ingress and clsact qdiscs to share filter blocks

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:   Thu, 11 Jan 2018 17:15:18 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        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 v7 09/13] net: sched: allow ingress and clsact
 qdiscs to share filter blocks

Thu, Jan 11, 2018 at 04:44:32PM CET, jhs@...atatu.com wrote:
>On 18-01-11 10:07 AM, Jiri Pirko wrote:
>> Thu, Jan 11, 2018 at 03:46:09PM CET, jhs@...atatu.com wrote:
>> > On 18-01-11 09:41 AM, Jiri Pirko wrote:
>> > > Thu, Jan 11, 2018 at 03:37:08PM CET, jhs@...atatu.com wrote:
>
>> > 
>> > I only looked at the kernel code. Good you can stop it at tc
>> > but the API does not stop it (unless you expect the rest of the
>> > world to only use tc).
>> 
>> Jamal, apparently, you did not looked at the kernel code either :)
>> Look at the changes done in net/sched/sch_ingress.c - there is where the
>> parsing of block attr takes place.
>> 
>
>reason i raised it is from looking at tc_ctl_tfilter().
>If i specify ifindex != TCM_IFINDEX_MAGIC_BLOCK,
>parent = 0XFFFF.... and block = 22 that should work, no?
>i.e regardless of whether parent is INGRESS etc.

No, the block needs to be created first by qdisc instance.
Seems to me that you are mixing apples and oranges a bit.


>
>And so i was confused why you had attributes in sch_ingress.c
>
>> 
>> > Really - there is no reason for this API to be only via ingress qdisc
>> > attributes. You can add a check in cls api to reject any parent that is
>> > not either of the clsacts + ingress (depending on tc doesnt sound
>> > right).
>> 
>> I was thinking to take this direction originally. To have another
>> generic attr called TCA_BLOCK or something that would be used when qdisc
>> is created. For ingress, what would work. But for clsact, you need to be
>> able to specify 2 block during qdisc creation - one for ingress, one for
>> egress. That's when I realized this has to be per-qdisc-type attr.
>> 
>
>ok for clsact - i can see that we dont have enough fields in the tcm
>message.

That is not a problem. Again, don't mix filter manipulation with qdisc
manipulation.


>
>TCA_BLOCK sounds appealing - could be a speacial tlv with many block ids
>maybe? I really would like to use this for egress as well - and what
>i described earlier should work for me.

I don't get what you mean by "tlv with many block ids". What is it good
for? :O


>
>cheers,
>jamal