On Mon, Apr 25, 2016 at 10:35:19PM +0100, Patrick McHardy wrote: > On 25.04, Florian Westphal wrote: > > Patrick McHardy <kaber@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
