From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next 1/3] netfilter: nftables: add connlabel set support
Date: Wed, 16 Mar 2016 00:09:21 +0100 [thread overview]
Message-ID: <20160315230921.GD8185@breakpoint.cc> (raw)
In-Reply-To: <20160315170813.GA25284@salvia>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Tue, Mar 15, 2016 at 05:10:09PM +0100, Florian Westphal wrote:
> > Instead of taking the value to set from a source register, userspace
> > passes the bit that we should set as a netlink attribute.
> >
> > This follows a similar approach that xtables 'connlabel'
> > match uses, so when user inputs
> >
> > ct label set bar
>
> I think we can introduce:
>
> ct label bitset bar
>
> so this is clear to the user this is just setting the bit at that
> position.
I don't like this one bit ;)
Seriously, I think "label set bar" is fine.
We already treat "ct label foo" correctly without
using "ct label testbit foo", so I like it better
without the extra special-case "bitset" keyword.
> > @@ -777,6 +778,7 @@ enum nft_ct_attributes {
> > NFTA_CT_KEY,
> > NFTA_CT_DIRECTION,
> > NFTA_CT_SREG,
> > + NFTA_CT_LABEL,
>
> We can probably add:
>
> NFTA_CT_IMM
Right, we can derive the exact type based on the key.
> This would be a nested attribute, then inside there we can define the:
>
> NFTA_CT_LABEL
Hmm, why a nested attribute?
What do we gain from that?
Do you want the nested attr so that we can define policies
for the "immediate subtypes"...?
If its the latter, then ok.
I'd then suggest adding a new enum, for instance:
NFTA_CT_IMM_LABEL
That appear as nested attrs inside the NFTA_CT_IMM one.
> > diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c
> > index d4a4619..76da69d 100644
> > --- a/net/netfilter/nft_ct.c
> > +++ b/net/netfilter/nft_ct.c
> > @@ -29,6 +29,7 @@ struct nft_ct {
> > enum nft_registers dreg:8;
> > enum nft_registers sreg:8;
> > };
> > + u8 set_label_bit;
>
> I understand a specific nft_ct_label is too much at this stage, so:
>
> union {
> u8 set_label_bit;
> } imm;
Right, using union imm looks good.
I'll rework this tomorrow, thanks for the quick review.
next prev parent reply other threads:[~2016-03-15 23:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 16:10 [RFC PATCH 0/3] connlabel set support using extra setter attr Florian Westphal
2016-03-15 16:10 ` [PATCH nf-next 1/3] netfilter: nftables: add connlabel set support Florian Westphal
2016-03-15 17:08 ` Pablo Neira Ayuso
2016-03-15 23:09 ` Florian Westphal [this message]
2016-03-16 9:39 ` Florian Westphal
2016-03-16 13:17 ` Pablo Neira Ayuso
2016-03-16 13:31 ` Florian Westphal
2016-03-16 13:35 ` Pablo Neira Ayuso
2016-03-16 13:18 ` Pablo Neira Ayuso
2016-03-15 16:10 ` [PATCH libnftl 2/3] ct: add label " Florian Westphal
2016-03-15 16:10 ` [PATCH nft 3/3] ct: add conntrack " Florian Westphal
2016-03-15 17:11 ` Pablo Neira Ayuso
2016-03-15 23:01 ` 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=20160315230921.GD8185@breakpoint.cc \
--to=fw@strlen.de \
--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).