[PATCH RFC] ct: endless loop when initializing netfilter/ct cache

Holger Eitzenberger holger at eitzenberger.org
Mon Nov 10 05:13:42 PST 2014


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.

 /Holger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libnl-avoid-dupe-check-on-initial-dump.diff
Type: text/x-diff
Size: 3180 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20141110/533b13ab/attachment.bin>


More information about the libnl mailing list