[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