Re: [nf-next RFC] netfilter: nf_tables: Feature ifname-based hook registration

[Florian Westphal <fw@strlen.de>]

Phil Sutter <phil@nwl.cc> wrote:
> Require user space to set a flag upon flowtable or netdev-family chain
> creation explicitly relaxing the hook registration when it comes to
> non-existent interfaces. For the sake of simplicity, just restore error
> condition if a given hook does not find an interface to bind to, leave
> everyting else in place.

OK, but then this needs to go in via nf.git and:

Fixes: 6d07a289504a ("netfilter: nf_tables: Support wildcard netdev hook specs")

tag.  We shouldn't introduce a "error" -> "no error" -> "error" semantic
change sequence in kernel releases, i.e. this change is urgent; its now
(before 6.16 release) or never.

> - A wildcard interface spec is accepted as long as at least a single
>   interface matches.

Is there a reason for this? Why are they handled differently?

> - Dynamic unregistering and re-registering of vanishing/re-appearing
>   interfaces is still happening.

You mean, without the flag? AFAIU old behaviour is:
For netdev chains:
- auto-removal AND free of device basechain -> no reappearance
- -ENOENT error on chain add if device name doesn't exist
For flowtable:
- device is removed from the list (and list can become empty), flowtable
  stays 100%, just the device name disappears from the devices list.
  Doesn't reappear (auto re-added) either.
- -ENOENT error on flowtable add if even one device doesn't exist

Neither netdev nor flowtable support "foo*" wildcards.

nf.git:
- netdev basechain kept alive, no freeing, auto-reregister (becomes
  active again if device with same name reappears).
  No error if device name doesn't exists -> delayed auto-register
  instead, including multi-reg for "foo*" case.
- flowtable: same as old BUT device is auto-(re)added if same name
  (re)appears.
- No -ENOENT error on flowtable add, even if no single device existed

Full "foo*" support.

Now (this patch, without new flag):
- netdev basechain: same as above.
  But you do get an error if the device name did not exist.
  Unless it was for "foo*", thats accepted even if no match is found.
  AFAICS its a userspace/nft change, ie. the new flag is actually
  provided silently in the "foo*" case?
- flowtable: same as old BUT device is auto-(re)added if same name
  (re)appears.
- -ENOENT error on flowtable add if even one device doesn't exist
  Except "foo*" case, then its ok even if no match found.

Maybe add a table that explains the old/new/wanted (this patch) behaviours?
And an explanation/rationale for the new flag?

Is there a concern that users depend on old behaviour?
If so, why are we only concerned about the "add" behaviour but not the
auto-reregistering?

Is it to protect users from typos going unnoticed?
I could imagine "wlp0s20f1" getting misspelled occasionally...

> Note that this flag is persistent, i.e. included in ruleset dumps. This
> effectively makes it "updatable": User space may create a "name-based"
> flowtable for a non-existent interface, then update the flowtable to
> drop the flag. What should happen then? Right now this is simply
> accepted, even though the flowtable still does not bind to an interface.

AFAIU:
If we accept off -> On, the flowtable should bind.
If we accept on -> off, then it looks we should continue to drop devices
from the list but just stop auto-readding?

If in doubt the flag should not be updateable (hard error), in
that case we can refine/relax later.