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