On 31/07/18 10:40 AM, Paolo Abeni wrote:
If we choose to reject unknown opcodes, such user-space configuration
will fail.
I think that is a good thing. The kernel should not be accepting things
it doesnt understand. This is a good opportunity to enforce that.
What would happen before this patch is that configurations using such
TC_ACT_XXXX value would be successful. This is why I proposed to keep
the fixup.
Note: Such behavior can only occur if tc(user space) allows you
to pass illegitimate values which today can only happen when you have a
new user space but older kernel (with "old" starting with your current
changes).
iow, fixing a policy in a kernel which has no support for TC_ACT_XXXX
to translate intent to be TC_ACT_OK/PIPE is problematic (as i was
showing earlier).
I initially thought the kernel behavior in the above scenario would
match exactly TC_ACT_UNSPEC processing, but as you noted with the
example in your previous email, TC_ACT_UNSPEC processing is actually a
bit different.
I worry: I dont think we can get a good default for most use
cases. No point in maintaining faulty expectations
(because IMO: the user will - eventually - fix their scripts if they
dont see expected behavior).
cheers,
jamal
