Re: [PATCH nf] netfilter: nf_conncount: increase connection clean up limit to 64

[Florian Westphal <fw@strlen.de>]

Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> On 12/16/25 4:25 PM, Florian Westphal wrote:
> > Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> > > 	if ((u32)jiffies == list->last_gc && (list->count - list->last_gc_count) >=
> > > CONNCOUNT_GC_MAX_NODES - 1)
> > > 	goto add_new_node;
> > 
> > Won't that rescan the same entries for as long as the condition
> > persists?
> > 
> > That was the reason for the move-to-tail, so we start with something
> > that we did not scan yet.
> > 
> 
> I do not follow here. AFAICT, the current loop is only breaking if collect
> is greater than CONNCOUNT_GC_MAX_NODES. That means, the loop must find 8
> closed connections or 8 errors (very unlikely) while trying to find the
> connection. If no connection is closed, the whole list is scanned.

What I mean is that:

188         /* check the saved connections */
189         list_for_each_entry_safe(conn, conn_n, &list->head, node) {
190                 if (collect > CONNCOUNT_GC_MAX_NODES)
191                         break;
192
193                 found = find_or_evict(net, list, conn);
194                 if (IS_ERR(found)) {
195                         /* Not found, but might be about to be confirmed */

The loop always starts with the beginning of the lists.
For existing scheme, we rescan every 1 jiffy.

With revised condition, we scan n times.  Without moving scanned
entries to the tail, we therefore query same list entries again.

I had proposed moving them off to the tail to avoid this, so when
doing another scan we start with an element that hasn't been scanned
yet.  This would also allow to alter the early-break conditions, e.g.

if (collected > CONNCOUNT_GC_MAX_NODES || jiffies != time_start)

or similar (wrt. your comment of triggering softlockup due to long
lists).

> I tested this quickly and seems to solve the problem too for a huge amount
> of connections (20000+). As the new adds while skipping the GC will never be
> bigger than what we are able to clean up during a GC.

OK, if its really good enough then lets do it, but I don't see how it avoids
any of the problems mentioned, in particular wrt. softlockup fears.