Subject: Re: [PATCH/RFC net-next 0/4] net/sched: cls_flower: avoid false matching of truncated packets

From: Simon Horman <[email-masked]>
Date: Fri, 28 Apr 2017 15:11:56 +0200

On Fri, Apr 28, 2017 at 08:52:56AM -0400, Jamal Hadi Salim wrote:
> On 17-04-28 08:00 AM, Simon Horman wrote:
> >Hi,
> >
> >this series is intended to avoid false-positives which match
> >truncated packets against flower classifiers which match on:
> >* zero L4 ports or;
> >* zero ICMP code or type
> >
> >This requires updating the flow dissector to return an error in such cases
> >and updating flower to not match on the result of a failed dissection.
> >
> >In the case of UDP this results in a behavioural change to users of
> >flow_keys_dissector_keys[] and flow_keys_dissector_symmetric_keys[] -
> >dissection will fail on truncated packets where the IP protocol of the
> >packets indicates ports should be present (according to skb_flow_get_ports()).
> 
> I think i understand the use case/need.
> But would it be fair to say that the truncated vs non-truncated are two
> different filter rules?

How would you describe such a rule? The case that is being dealt with is
one where there is a parse error and thus nothing to match on from a flower
pov.

> Example what would offloading of
> header_parse_err_action mean?

Why would it need to differ semantically to the implementation in this
patch? I feel that I am missing something.