From: Simon Horman <simon.horman@netronome•com>
To: Jamal Hadi Salim <jhs@mojatatu•com>
Cc: Jiri Pirko <jiri@mellanox•com>,
Cong Wang <xiyou.wangcong@gmail•com>,
Dinan Gunawardena <dinan.gunawardena@netronome•com>,
netdev@vger•kernel.org, oss-drivers@netronome•com
Subject: Re: [PATCH/RFC net-next 0/4] net/sched: cls_flower: avoid false matching of truncated packets
Date: Fri, 28 Apr 2017 15:11:56 +0200 [thread overview]
Message-ID: <20170428131155.GA30329@vergenet.net> (raw)
In-Reply-To: <422d55da-f861-1bc6-983d-199fc383c113@mojatatu.com>
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.
next prev parent reply other threads:[~2017-04-28 13:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-28 12:00 [PATCH/RFC net-next 0/4] net/sched: cls_flower: avoid false matching of truncated packets Simon Horman
2017-04-28 12:00 ` [PATCH/RFC net-next 1/4] flow dissector: return error on port dissection under-run Simon Horman
2017-04-28 12:00 ` [PATCH/RFC net-next 2/4] flow dissector: return error on icmp " Simon Horman
2017-04-28 12:00 ` [PATCH/RFC net-next 3/4] net/sched: cls_flower: do not match if dissection fails Simon Horman
2017-04-28 12:00 ` [PATCH/RFC net-next 4/4] net/sched: cls_flower: allow control of tree traversal on packet parse errors Simon Horman
2017-04-28 12:52 ` [PATCH/RFC net-next 0/4] net/sched: cls_flower: avoid false matching of truncated packets Jamal Hadi Salim
2017-04-28 13:11 ` Simon Horman [this message]
2017-04-28 13:41 ` Jamal Hadi Salim
2017-04-28 14:14 ` Simon Horman
2017-04-30 13:51 ` Jamal Hadi Salim
2017-04-30 14:45 ` Jamal Hadi Salim
2017-05-01 10:36 ` Simon Horman
2017-05-02 1:35 ` Jamal Hadi Salim
2017-05-02 12:04 ` [oss-drivers] " Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170428131155.GA30329@vergenet.net \
--to=simon.horman@netronome$(echo .)com \
--cc=dinan.gunawardena@netronome$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=jiri@mellanox$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=oss-drivers@netronome$(echo .)com \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox