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

[Patrick McHardy <kaber@trash.net>]

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?