On Thu, Jan 10, 2019 at 5:42 AM Edward Cree <ec...@solarflare.com> wrote: > > I think there is a bug in net/sched/cls_flower.c:fl_init_dissector(), > where it reads > > FL_KEY_SET_IF_MASKED(mask, keys, cnt, > FLOW_DISSECTOR_KEY_IPV4_ADDRS, ipv4); > FL_KEY_SET_IF_MASKED(mask, keys, cnt, > FLOW_DISSECTOR_KEY_IPV6_ADDRS, ipv6); > > (and correspondingly further down for enc IP addrs), in that fl_flow_key > stores ipv4 and ipv6 in a union, meaning that if a tc flower filter sets, > for instance, a destination IPv4 address (and an ethertype of IPv4), the > mask for this will also show up in the middle of the source ipv6 address, > and lead to the ipv6 key being marked as used. Thus subsequently a call > to dissector_uses_key(..., FLOW_DISSECTOR_KEY_IPV6_ADDRS) will return > true. > While this can be disambiguated by examining key->control.addr_type, this > seems like it ought not to be necessary. I apologise if this has been > asked before, but is there a reason why the core code cannot fix this up > and prevent drivers from seeing it in their tc offload routines?
I don't follow this question. The code you quoted from fl_init_dissector() is correct, as it merely stores the offsets of ipv4/ipv6 fields. If somewhere we use it without checking control.addr_type, then it is a bug there. I don't see anything particular here, we use IPv4/IPv6 address union in so many other places in networking, I don't see why this one is so special to you. :) Thanks.
