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]
Date:   Thu, 4 Jan 2018 08:30:54 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jakub Kicinski <kubakici@...pl>, 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, 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 v4 00/10] net: sched: allow qdiscs to share
 filter block instances

On 18-01-04 08:00 AM, Jiri Pirko wrote:
> Thu, Jan 04, 2018 at 01:41:54PM CET, jhs@...atatu.com wrote:


>>
>> And that a simple "tc qdisc add dev ens7 ingress" should
>> either not be able to create a block (or we can say creates
>> block id 0 - owned by the netdev - for consistency).
> 
> This allocates a new block - as it needs it internally anyway - and tc
> core will assign unused block id. You can see this id in the list then.
> Later you can use this block id for other created qdiscs.
> 
> Block ids are per-ns.
>

Hrm. I was thinking more that there is a block that cannot be shared
and is only owned by the netdev i.e current behavior. But what you
describe should work
(and let the user decide if they want to share).

>>
>> Maybe what we need is another knob to control this new functionality?
>> Either a kernel config option or an extra parameter when creating
>> the qdisc or a system wide boolean per netdev (which of course
>> contradicts the "less is more" principle). If this knob was set
>> then you reject addition of filters via a port/qdisc which is sharing.
> 
> I don't like this knob idea. It just adds confusion for no good reason
> what so ever.

I dont like it either but i see it as a knob to choose between
improved usability/manageability (which new interface provides)
vs least suprise - which is to keep the old syntax around.
If i was an admin and turned on this knob - I am prepared to deal
with fallout of some user script which tries to add filters via
the device instead of the block.

cheers,
jamal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ