From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft 2/2] src: propagate key datatype for anonymous sets
Date: Thu, 16 Dec 2021 00:22:58 +0100 [thread overview]
Message-ID: <Ybp40gmoXMtPpDDm@salvia> (raw)
In-Reply-To: <20211209151131.22618-3-fw@strlen.de>
On Thu, Dec 09, 2021 at 04:11:31PM +0100, Florian Westphal wrote:
> set s10 {
> typeof tcp option mptcp subtype
> elements = { mp-join, dss }
> }
>
> is listed correctly: typeof provides the 'mptcpopt_subtype'
> datatype, so listing will print the elements with their sybolic types.
>
> In anon case this doesn't work:
> tcp option mptcp subtype { mp-join, dss }
>
> gets shown as 'tcp option mptcp subtype { 1, 2}' because the anon
> set has integer type.
>
> This change propagates the datatype to the individual members
> of the anon set.
>
> After this change, multiple existing data types such as
> TYPE_ICMP_TYPE could be replaced by integer-type aliases, but those
> data types are already exposed to userspace via the 'set type'
> directive so doing this may break existing set definitions.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> src/expression.c | 34 ++++++++++++++++++++++++++++++++++
> tests/py/any/tcpopt.t | 2 +-
> tests/py/any/tcpopt.t.payload | 10 +++++-----
> 3 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/src/expression.c b/src/expression.c
> index f1cca8845376..9de70c6cc1a4 100644
> --- a/src/expression.c
> +++ b/src/expression.c
> @@ -1249,6 +1249,31 @@ static void set_ref_expr_destroy(struct expr *expr)
> set_free(expr->set);
> }
>
> +static void set_ref_expr_set_type(const struct expr *expr,
> + const struct datatype *dtype,
> + enum byteorder byteorder)
> +{
> + const struct set *s = expr->set;
> +
> + /* normal sets already have a precise datatype that is given in
> + * the set definition via type foo.
> + *
> + * Anon sets do not have this, and need to rely on type info
> + * generated at rule creation time.
> + *
> + * For most cases, the type info is correct.
> + * In some cases however, the kernel only stores TYPE_INTEGER.
> + *
> + * This happens with expressions that only use an integer alias
> + * type, such as mptcp_suboption.
> + *
> + * In this case nft would print '1', '2', etc. instead of symbolic
> + * names because the base type lacks ->sym_tbl information.
> + */
> + if (s->init && set_is_anonymous(s->flags))
> + expr_set_type(s->init, dtype, byteorder);
Will this work with concatenations?
next prev parent reply other threads:[~2021-12-15 23:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 15:11 [PATCH 0/2 nft] mptcp: add mptcp subtype mnemonics Florian Westphal
2021-12-09 15:11 ` [PATCH nft 1/2] tcpopt: add phony mptcp suboption datatype Florian Westphal
2021-12-09 15:11 ` [PATCH nft 2/2] src: propagate key datatype for anonymous sets Florian Westphal
2021-12-15 23:22 ` Pablo Neira Ayuso [this message]
2021-12-17 11:22 ` Florian Westphal
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=Ybp40gmoXMtPpDDm@salvia \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.