Re: [PATCH v6 -next 2/4] netfilter: nftables: add connlabel set support

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Apr 25, 2016 at 10:35:19PM +0100, Patrick McHardy wrote:
> On 25.04, Florian Westphal wrote:
> > Patrick McHardy <kaber@trash.net> wrote:
> > > On 25.04, Florian Westphal wrote:
> > > > We could go for a 3rd alternative, namely:
> > > > 
> > > > u16 bit = regs->data[priv->sreg];
> > > > set_bit(bit, ct->labels);
> > > > 
> > > > i.e. have userspace place the _bit_ that we want to set in the
> > > > source register.
> > > > 
> > > > If we go for sreg that would be my favored solution.
> > > > 
> > > > The only drawback vs #1 is that get and set work differently
> > > > (get places all labels into dreg, set expects bit to set).
> > > 
> > > That seems like a problem. I agree that #3 would generally be fine, but
> > > we should also really have "ct labels set ct labels" not change the labels,
> > > that would be highly counterintuitive.
> > 
> > Right.  What about just re-working this approach:
> > 
> > https://patchwork.ozlabs.org/patch/613136/
> > 
> > (sans the CT_IMM part)?  We'd reject all expressions other than
> > EXPR_VALUE in the eval phase -- 'ct labels set ct labels' would yield
> > 'label expected' error message.
> > 
> > Does that seem acceptable to you?
> 
> Well, that pretty much defeats the use of the sreg since we can't use maps
> or any other way to derive the label.
> 
> > If not, I see no choice other than resubmitting the original V1 kernel
> > patch that simply copied the entire sreg into the label area, this way
> > no userspace changes are needed.
> 
> I have to follow up on the previous discussion. Just wondering, what's wrong
> with simply memcpy'ing and supplying the full set of labels?

How can you make this atomic with a 128 bit connlabel?