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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <571e2252-61e4-11b7-edc1-f82cd7b69cc0@mojatatu.com>
Date:   Sat, 6 Jan 2018 13:16:10 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     David Ahern <dsahern@...il.com>, Jiri Pirko <jiri@...nulli.us>
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
Subject: Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share
 filter block instances

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
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