• Daniel Borkmann's avatar
    net, cls: allow for deleting all filters for given parent · ea7f8277
    Daniel Borkmann authored
    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:
    
      # tc qdisc replace dev foo clsact
      # tc filter add dev foo egress bpf da obj ./bpf.o
      # tc filter add dev foo egress bpf da obj ./bpf.o
      # tc filter show dev foo egress
      filter protocol all pref 49151 bpf
      filter protocol all pref 49151 bpf handle 0x1 bpf.o:[classifier] direct-action
      filter protocol all pref 49152 bpf
      filter protocol all pref 49152 bpf handle 0x1 bpf.o:[classifier] direct-action
      # tc filter del dev foo egress
      # tc filter show dev foo egress
      #
    
    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: default avatarDaniel Borkmann <daniel@iogearbox.net>
    Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
    Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    ea7f8277
cls_api.c 15.1 KB