On Tue, 2018-07-31 at 09:53 -0400, Jamal Hadi Salim wrote: > BTW, I asked this earlier and Jiri said it was addressed in patch 2. > I just looked again and i may be missing something basic: > Lets say tomorrow in a new kernel we add new TC_ACT_XXX that then gets > exposed to uapi - so user space tc is updated. > You then use the new tc specifying TC_ACT_XXX policy on kernel with your > changes. > If i read correctly because TC_ACT_XXX is out of bounds for current > kernel(which has your changes) you will fix it to be UNSPEC, no?
You are right. If we choose to reject unknown opcodes, such user-space configuration will fail. 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. 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. Cheers, Paolo
