Re: [PATCH RFC v2] netfilter: add connlabel conntrack extension

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

On Thu, Nov 15, 2012 at 01:50:02PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Mon, Nov 12, 2012 at 01:47:05PM +0100, Florian Westphal wrote:
> > > Alternative would be to keep track of highest bit requested in a "-m connlabel"
> > > rule to figure out the needed size.
> > > 
> > > In any case, it would require adding "u16 len" to the extension area; else
> > > we can't figure out how many bytes are valid, i.e.:
> > > 
> > > struct nf_conn_labels {
> > > +       u16 size;		/* length of label storage */
> > > +	unsigned long bits[];	/* variable-sized label storage */
> > > +};
> > > 
> > > it would increase minimum length needed but it would avoid
> > > the rcu dances done by the current scheme.
> > > 
> > > It this is ok for you I'll make this change to see how many LOC are
> > > saved by this.
> > 
> > If we simplify the current connlabel code it would be great. And so
> > far, the only way I can think to obtain that is to explictly specify
> > via the CT target the length of the label.
> 
> I've turned it into a var-length extension, so all the rcu dances
> and runtime reallocs are gone.
> 
> I'll be sending the first non-rfc version of the patchset soon.
> 
> Minor drawback: I had to reduce it to 128 labels max, else the
> extension offset array (u8 offset[]) will overflow if too many
> extensions are enabled.

Good point. That reminds me that we should add some bugtrap to
net/netfilter/nf_conntrack_extend.c to check for such possible
overflows.

> At the moment the 128 labels max constraint is no problem at all,
> and we can increase it later if we reduce total possible extension
> size (or use u16 for length/offset tracking).

Sure.