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? -- 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
