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?

-Ed

Reply via email to