[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