[PATCH RFC] ct: endless loop when initializing netfilter/ct cache
Thomas Graf
tgraf at suug.ch
Mon Nov 10 06:18:39 PST 2014
On 11/10/14 at 02:13pm, Holger Eitzenberger wrote:
> Hi Thomas,
>
> > > Yes, the insert is O(n^2) since introducing dup check. With
> > > thousands of conntracks it is currently unusable.
> > >
> > > If you want I can cook an RFC path for that.
> >
> > That sounds great. Thanks!
>
> The cache flags are currently set from cache_ops, it would be a compile
> time decision whether to use caching or not or a subusystem. So
> it would eventually require to pass user-specified flags to
> the cache creating functions.
>
> But I think there is a smarter way.
>
> The actual issue is in nl_cache_refill(). I noticed that it
> explicitely clears the cache before, then doing the dump request.
> So in this case it makes sense to just skip the dupe check in
> nl_cache_pickup(), because the dump AFAIK guarantees uniqueness.
>
> But there is another user of nl_cache_pickup() in flnl_lookup(), which
> requires the dupe check. So we just can't remove dupe check entirely.
>
> I therefore have modified nl_cache_pickup() to have an additional 3rd
> argument, which tells whether dupe_check is required or not. Since
> nl_cache_pickup is a non-static function this then is an API change.
>
> Also note that last argument ideally would be C99 'bool', but
> stdbool.h currently is not #included anywhere - and I therefore chose
> 'int' instead. Should I change signature to use 'bool' instead?
>
> Please check RFC patch.
I like the dup avoidance change to nl_cache_pickup() to work around
this automatically but we can't modify the signature of
nl_cache_pickup() as it breaks both API and ABI.
What we can do is add a new nl_cache_pickup_checkdup() which can be
used from within flnl_lookup() to keep the DUP check and modify the
standard behaviour of nl_cache_pickup() to not do a DUP check.
More information about the libnl
mailing list