netdev - Re: [PATCH net-next v2] net, cls: allow for deleting all filters for given parent

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] [day] [month] [year] [list]

Date:	Fri, 10 Jun 2016 18:15:08 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	daniel@...earbox.net
Cc:	xiyou.wangcong@...il.com, jhs@...atatu.com,
	alexei.starovoitov@...il.com, john.fastabend@...il.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2] net, cls: allow for deleting all filters
 for given parent

From: Daniel Borkmann <daniel@...earbox.net>
Date: Fri, 10 Jun 2016 23:10:22 +0200

> Add a possibility where the user can just specify the parent and
> all filters under that parent are then being purged. Currently,
> for example for scripting, one needs to specify pref/prio to have
> a well-defined number for 'tc filter del' command for addressing
> the previously created instance or additionally filter handle in
> case of priorities being the same. Improve usage by allowing the
> option for tc to specify the parent and removing the whole chain
> for that given parent.
> 
> Example usage after patch, no tc changes required:
 ...
> Previously, RTM_DELTFILTER requests with invalid prio of 0 were
> rejected, so only netlink requests with RTM_NEWTFILTER and NLM_F_CREATE
> flag were allowed where the kernel would auto-generate a pref/prio.
> We can piggyback on that and use prio of 0 as a wildcard for
> requests of RTM_DELTFILTER.
> 
> For notifying tc netlink monitoring users (e.g. libnl uses this
> for caching), there are two options, that is, sending individual
> tfilter_notify() notifications for each tcf_proto, or sending a
> single one indicating wildcard removal. I tried both and there
> are pros and cons for each, eventually I decided for sending
> individual tfilter_notify(), so that user space can support this
> seamlessly and there won't be a mess of changing each and every
> application to make sure expectations from the kernel won't break
> when they don't understand single notification. Since linear chains
> don't really scale, I expect only a handful of classifiers to be
> attached at max for a given parent anyway.
> 
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> Acked-by: Jamal Hadi Salim <jhs@...atatu.com>

Applied.