netdev - Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share filter block instances

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, 6 Jan 2018 21:38:54 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     David Ahern <dsahern@...il.com>, 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
Subject: Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share
 filter block instances

Sat, Jan 06, 2018 at 07:16:10PM CET, jhs@...atatu.com wrote:
>On 18-01-06 12:41 PM, David Ahern wrote:
>> On 1/6/18 1:07 AM, Jiri Pirko wrote:
>> > Sat, Jan 06, 2018 at 04:57:21AM CET, dsahern@...il.com wrote:
>> > > On 1/5/18 4:09 PM, Jiri Pirko wrote:
>> > > > From: Jiri Pirko <jiri@...lanox.com>
>> > > > 
>
>> > > 
>> > > $ tc filter show block 22
>> > > $ echo $?
>> > > 0
>> > > $  tc qdisc show | grep block
>> > > qdisc ingress ffff: dev eth2 parent ffff:fff1 block 42
>> > 
>> > Yeah, I will try to fix this. The thing is, this is not error by kernel
>> > but by the userspace. Kernel is perfectly ok with invalid device or
>> > block index, it just does not dump anything and I would leave it like
>> > that. I have to somehow check the validity of block_index in userspace.
>> > Not sure how now.
>> 
>> Ok. I saw a response about idr_alloc_ext.
>> 
>> Here's another one: adding a filter to an unknown block id:
>> 
>> $ tc filter add block 66 ingress protocol ip pref 1 flower dst_ip
>
>
>BTW, above syntax looks redundant because of the ingress parent
>specification. It is possible iproute2/tc is just ignoring it right now

I'm sure that is just a typo on DaveA's side.


>and the parent is not being used.
>i.e Once the block is bound to ingress (aka parent ffff:) via:
>qdisc ingress ffff: dev eth2 parent ffff:fff1 block 42
>then
>it doesnt make sense to specify a parent again because
>it should be possible to bind that block to many parent locations
>eg clsact ingress of dev x and clsact egress of dev y.
>
>what am i missing?
>
>cheers,
>jamal