From: Stephen Hemminger <stephen@networkplumber.org>
To: Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: netdev@vger.kernel.org, Jiri Pirko <jiri@resnulli.us>
Subject: Re: [PATCH iproute2] police: don't skip parameters after actions
Date: Mon, 29 Jan 2018 08:07:23 -0800 [thread overview]
Message-ID: <20180129080723.5f2b5311@xeon-e3> (raw)
In-Reply-To: <20180129111311.21610-1-w.bumiller@proxmox.com>
On Mon, 29 Jan 2018 12:13:11 +0100
Wolfgang Bumiller <w.bumiller@proxmox.com> wrote:
> The 'parse_action_control()' helper advances the argument
> pointers to past its parsed action already, so don't
> advance it further in 'act_parse_polic()'.
>
> Fixes: e67aba559581 ("tc: actions: add helpers to parse and print control actions")
> Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
> ---
> Basically parse_action_control() silently added a NEXT_ARG() while the
> cases before didn't have one. Not sure whether the goto is okay
> style-wise, let me know if you prefer some other solution.
>
> Example for triggering this:
> Specifying a 'flowid X' after a `police ... drop` will skip the 'flowid'
> and error with "What is X"
>
> $ tc filter add dev eth0 parent ffff: basic police rate 13371337bps burst 1337b mtu 64kb drop flowid :1
> What is ":1"?
Thank you for the patch. It is a real problem, and your patch addresses it.
I just don't like jumping around in the the argument parsing with goto's.
There was a similar problem recently, and the better fix was to fix the semantics
of the parsing function to not do the extra implicit NEXT_ARG in the parsing logic.
There is less likely to be future problems if all parsing functions leave the
with the same argument location.
Please try that and resubmit.
next prev parent reply other threads:[~2018-01-29 16:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-29 11:13 [PATCH iproute2] police: don't skip parameters after actions Wolfgang Bumiller
2018-01-29 16:07 ` Stephen Hemminger [this message]
2018-01-31 13:23 ` Wolfgang Bumiller
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=20180129080723.5f2b5311@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=w.bumiller@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).