On Thu, Nov 15, 2012 at 01:50:02PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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.
--
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
