From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 1/3 nft] parser: get rid of multiton_expr from lhs relational expression
Date: Mon, 4 Jan 2016 22:48:53 +0000 [thread overview]
Message-ID: <20160104171238.GC32583@macbook.localdomain> (raw)
In-Reply-To: <1451419755-29997-1-git-send-email-pablo@netfilter.org>
On 29.12, Pablo Neira Ayuso wrote:
> The multiton_expr rule matches range, prefix and wildcard expressions
> which don't make sense from the non-constant lhs. This rule is there to
> handle the nat statement case, whose expression may be composed of
> address and port ranges (hence range expressions).
Its actually originates from set expressions. As long as we can still use
it there and can use bitwise and similar expressions for both sets and
maps this seems fine.
> To resolve this, this patch adds the stmt_expr rule to handle the
> possible occurrences of map, multiton and primary expressions from
> statements.
>
> This results in more rules but it narrows down what we can find from
> expressions that are part of action statements.
I had a similar patch which simply split it up into lhs and rhs expressions.
Using stmt_expr seems a bit limited considering that we already use it for
other things than statements.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
> src/parser_bison.y | 54 ++++++++++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 44 insertions(+), 10 deletions(-)
>
> diff --git a/src/parser_bison.y b/src/parser_bison.y
> index d42bd2f..b49eadb 100644
> --- a/src/parser_bison.y
> +++ b/src/parser_bison.y
> @@ -486,6 +486,10 @@ static void location_update(struct location *loc, struct location *rhs, int n)
> %destructor { expr_free($$); } multiton_expr
> %type <expr> prefix_expr range_expr wildcard_expr
> %destructor { expr_free($$); } prefix_expr range_expr wildcard_expr
> +
> +%type <expr> stmt_expr concat_stmt_expr map_stmt_expr
> +%destructor { expr_free($$); } stmt_expr concat_stmt_expr map_stmt_expr
> +
> %type <expr> list_expr
> %destructor { expr_free($$); } list_expr
> %type <expr> concat_expr
> @@ -1577,20 +1581,51 @@ nat_stmt_alloc : SNAT
> }
> ;
>
> -nat_stmt_args : expr
> +concat_stmt_expr : primary_expr
> + | concat_stmt_expr DOT primary_expr
> + {
> + if ($$->ops->type != EXPR_CONCAT) {
> + $$ = concat_expr_alloc(&@$);
> + compound_expr_add($$, $1);
> + } else {
> + struct location rhs[] = {
> + [1] = @2,
> + [2] = @3,
> + };
> + location_update(&$3->location, rhs, 2);
> +
> + $$ = $1;
> + $$->location = @$;
> + }
> + compound_expr_add($$, $3);
> + }
> + ;
> +
> +map_stmt_expr : concat_stmt_expr MAP rhs_expr
> + {
> + $$ = map_expr_alloc(&@$, $1, $3);
> + }
> + ;
> +
> +stmt_expr : map_stmt_expr
> + | multiton_expr
> + | primary_expr
> + ;
> +
> +nat_stmt_args : stmt_expr
> {
> $<stmt>0->nat.addr = $1;
> }
> - | expr COLON expr
> + | stmt_expr COLON stmt_expr
> {
> $<stmt>0->nat.addr = $1;
> $<stmt>0->nat.proto = $3;
> }
> - | COLON expr
> + | COLON stmt_expr
> {
> $<stmt>0->nat.proto = $2;
> }
> - | nat_stmt_args nf_nat_flags
> + | nat_stmt_args nf_nat_flags
> {
> $<stmt>0->nat.flags = $2;
> }
> @@ -1614,7 +1649,7 @@ redir_stmt : redir_stmt_alloc redir_stmt_arg
> redir_stmt_alloc : REDIRECT { $$ = redir_stmt_alloc(&@$); }
> ;
>
> -redir_stmt_arg : TO expr
> +redir_stmt_arg : TO stmt_expr
> {
> $<stmt>0->redir.proto = $2;
> }
> @@ -1622,19 +1657,19 @@ redir_stmt_arg : TO expr
> {
> $<stmt>0->redir.flags = $1;
> }
> - | TO expr nf_nat_flags
> + | TO stmt_expr nf_nat_flags
> {
> $<stmt>0->redir.proto = $2;
> $<stmt>0->redir.flags = $3;
> }
> ;
>
> -dup_stmt : DUP TO expr
> +dup_stmt : DUP TO stmt_expr
> {
> $$ = dup_stmt_alloc(&@$);
> $$->dup.to = $3;
> }
> - | DUP TO expr DEVICE expr
> + | DUP TO stmt_expr DEVICE stmt_expr
> {
> $$ = dup_stmt_alloc(&@$);
> $$->dup.to = $3;
> @@ -1671,7 +1706,7 @@ queue_stmt_args : queue_stmt_arg
> | queue_stmt_args queue_stmt_arg
> ;
>
> -queue_stmt_arg : QUEUENUM expr
> +queue_stmt_arg : QUEUENUM stmt_expr
> {
> $<stmt>0->queue.queue = $2;
> }
> @@ -1865,7 +1900,6 @@ map_expr : concat_expr MAP rhs_expr
> ;
>
> expr : concat_expr
> - | multiton_expr
> | set_expr
> | map_expr
> ;
> --
> 2.1.4
>
prev parent reply other threads:[~2016-01-04 22:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-29 20:09 [PATCH 1/3 nft] parser: get rid of multiton_expr from lhs relational expression Pablo Neira Ayuso
2015-12-29 20:09 ` [PATCH 2/3 nft] parser: rename multiton_expr to multiton_rhs_expr Pablo Neira Ayuso
2015-12-29 20:09 ` [PATCH 3/3 nft] parser: restore bitwise operations from the rhs of relational expressions Pablo Neira Ayuso
2016-01-04 22:48 ` Patrick McHardy [this message]
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=20160104171238.GC32583@macbook.localdomain \
--to=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/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).