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

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

[Fernando Fernandez Mancera]

After the optimization to only perform one GC per jiffy, a new problem
was introduced. If more than 8 new connections are tracked per jiffy the
list won't be cleaned up fast enough possibly reaching the limit
wrongly.

In order to prevent this issue, increase the clean up limit to 64
connections so it is easier for conncount to keep up with the new
connections tracked per jiffy rate.

Fixes: d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC")
Reported-by: Aleksandra Rukomoinikova <ARukomoinikova@k2.cloud>
Closes: https://lore.kernel.org/netfilter/b2064e7b-0776-4e14-adb6-c68080987471@k2.cloud/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
 net/netfilter/nf_conncount.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/netfilter/nf_conncount.c b/net/netfilter/nf_conncount.c
index 3654f1e8976c..ec134729856f 100644
--- a/net/netfilter/nf_conncount.c
+++ b/net/netfilter/nf_conncount.c
@@ -34,8 +34,9 @@
 
 #define CONNCOUNT_SLOTS		256U
 
-#define CONNCOUNT_GC_MAX_NODES	8
-#define MAX_KEYLEN		5
+#define CONNCOUNT_GC_MAX_NODES		8
+#define CONNCOUNT_GC_MAX_COLLECT	64
+#define MAX_KEYLEN			5
 
 /* we will save the tuples of all connections we care about */
 struct nf_conncount_tuple {
@@ -187,7 +188,7 @@ static int __nf_conncount_add(struct net *net,
 
 	/* check the saved connections */
 	list_for_each_entry_safe(conn, conn_n, &list->head, node) {
-		if (collect > CONNCOUNT_GC_MAX_NODES)
+		if (collect > CONNCOUNT_GC_MAX_COLLECT)
 			break;
 
 		found = find_or_evict(net, list, conn);
@@ -316,7 +317,7 @@ static bool __nf_conncount_gc_list(struct net *net,
 		}
 
 		nf_ct_put(found_ct);
-		if (collected > CONNCOUNT_GC_MAX_NODES)
+		if (collected > CONNCOUNT_GC_MAX_COLLECT)
 			break;
 	}
 
-- 
2.51.1

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

[Rukomoinikova Aleksandra]

Hi, thanks so much for fix)

On 16.12.2025 15:24, Fernando Fernandez Mancera wrote:
> After the optimization to only perform one GC per jiffy, a new problem
> was introduced. If more than 8 new connections are tracked per jiffy the
> list won't be cleaned up fast enough possibly reaching the limit
> wrongly.
>
> In order to prevent this issue, increase the clean up limit to 64
> connections so it is easier for conncount to keep up with the new
> connections tracked per jiffy rate.
>
> Fixes: d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC")
> Reported-by: Aleksandra Rukomoinikova <ARukomoinikova@k2.cloud>
> Closes: https://lore.kernel.org/netfilter/b2064e7b-0776-4e14-adb6-c68080987471@k2.cloud/
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> ---
>   net/netfilter/nf_conncount.c | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/nf_conncount.c b/net/netfilter/nf_conncount.c
> index 3654f1e8976c..ec134729856f 100644
> --- a/net/netfilter/nf_conncount.c
> +++ b/net/netfilter/nf_conncount.c
> @@ -34,8 +34,9 @@
>   
>   #define CONNCOUNT_SLOTS		256U
>   
> -#define CONNCOUNT_GC_MAX_NODES	8
> -#define MAX_KEYLEN		5
> +#define CONNCOUNT_GC_MAX_NODES		8
> +#define CONNCOUNT_GC_MAX_COLLECT	64
> +#define MAX_KEYLEN			5
>   
>   /* we will save the tuples of all connections we care about */
>   struct nf_conncount_tuple {
> @@ -187,7 +188,7 @@ static int __nf_conncount_add(struct net *net,
>   
>   	/* check the saved connections */
>   	list_for_each_entry_safe(conn, conn_n, &list->head, node) {
> -		if (collect > CONNCOUNT_GC_MAX_NODES)
> +		if (collect > CONNCOUNT_GC_MAX_COLLECT)
>   			break;
>   
>   		found = find_or_evict(net, list, conn);
> @@ -316,7 +317,7 @@ static bool __nf_conncount_gc_list(struct net *net,
>   		}
>   
>   		nf_ct_put(found_ct);
> -		if (collected > CONNCOUNT_GC_MAX_NODES)
> +		if (collected > CONNCOUNT_GC_MAX_COLLECT)
>   			break;
>   	}
>   


-- 
regards,
Alexandra.

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

[Fernando Fernandez Mancera]

On 12/16/25 1:44 PM, Rukomoinikova Aleksandra wrote:
> Hi, thanks so much for fix)
> 

Aleksandra, if you could test it and provide your Tested-by: tag it 
would be quite helpful. I tested this fix with 
nft_connlimit/xt_connlimit and also with OVS zone-limit feature.

> On 16.12.2025 15:24, Fernando Fernandez Mancera wrote:
>> After the optimization to only perform one GC per jiffy, a new problem
>> was introduced. If more than 8 new connections are tracked per jiffy the
>> list won't be cleaned up fast enough possibly reaching the limit
>> wrongly.
>>
>> In order to prevent this issue, increase the clean up limit to 64
>> connections so it is easier for conncount to keep up with the new
>> connections tracked per jiffy rate.
>>
>> Fixes: d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC")
>> Reported-by: Aleksandra Rukomoinikova <ARukomoinikova@k2.cloud>
>> Closes: https://lore.kernel.org/netfilter/b2064e7b-0776-4e14-adb6-c68080987471@k2.cloud/
>> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
>> ---
>>    net/netfilter/nf_conncount.c | 9 +++++----
>>    1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/netfilter/nf_conncount.c b/net/netfilter/nf_conncount.c
>> index 3654f1e8976c..ec134729856f 100644
>> --- a/net/netfilter/nf_conncount.c
>> +++ b/net/netfilter/nf_conncount.c
>> @@ -34,8 +34,9 @@
>>    
>>    #define CONNCOUNT_SLOTS		256U
>>    
>> -#define CONNCOUNT_GC_MAX_NODES	8
>> -#define MAX_KEYLEN		5
>> +#define CONNCOUNT_GC_MAX_NODES		8
>> +#define CONNCOUNT_GC_MAX_COLLECT	64
>> +#define MAX_KEYLEN			5
>>    
>>    /* we will save the tuples of all connections we care about */
>>    struct nf_conncount_tuple {
>> @@ -187,7 +188,7 @@ static int __nf_conncount_add(struct net *net,
>>    
>>    	/* check the saved connections */
>>    	list_for_each_entry_safe(conn, conn_n, &list->head, node) {
>> -		if (collect > CONNCOUNT_GC_MAX_NODES)
>> +		if (collect > CONNCOUNT_GC_MAX_COLLECT)
>>    			break;
>>    
>>    		found = find_or_evict(net, list, conn);
>> @@ -316,7 +317,7 @@ static bool __nf_conncount_gc_list(struct net *net,
>>    		}
>>    
>>    		nf_ct_put(found_ct);
>> -		if (collected > CONNCOUNT_GC_MAX_NODES)
>> +		if (collected > CONNCOUNT_GC_MAX_COLLECT)
>>    			break;
>>    	}
>>    
> 
> 

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

[Rukomoinikova Aleksandra]

Yes, sure, i will test it today.

On 16.12.2025 16:07, Fernando Fernandez Mancera wrote:
>
>
> On 12/16/25 1:44 PM, Rukomoinikova Aleksandra wrote:
>> Hi, thanks so much for fix)
>>
>
> Aleksandra, if you could test it and provide your Tested-by: tag it 
> would be quite helpful. I tested this fix with 
> nft_connlimit/xt_connlimit and also with OVS zone-limit feature.
>
>> On 16.12.2025 15:24, Fernando Fernandez Mancera wrote:
>>> After the optimization to only perform one GC per jiffy, a new problem
>>> was introduced. If more than 8 new connections are tracked per jiffy 
>>> the
>>> list won't be cleaned up fast enough possibly reaching the limit
>>> wrongly.
>>>
>>> In order to prevent this issue, increase the clean up limit to 64
>>> connections so it is easier for conncount to keep up with the new
>>> connections tracked per jiffy rate.
>>>
>>> Fixes: d265929930e2 ("netfilter: nf_conncount: reduce unnecessary GC")
>>> Reported-by: Aleksandra Rukomoinikova <ARukomoinikova@k2.cloud>
>>> Closes: 
>>> https://lore.kernel.org/netfilter/b2064e7b-0776-4e14-adb6-c68080987471@k2.cloud/
>>> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
>>> ---
>>>    net/netfilter/nf_conncount.c | 9 +++++----
>>>    1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/netfilter/nf_conncount.c 
>>> b/net/netfilter/nf_conncount.c
>>> index 3654f1e8976c..ec134729856f 100644
>>> --- a/net/netfilter/nf_conncount.c
>>> +++ b/net/netfilter/nf_conncount.c
>>> @@ -34,8 +34,9 @@
>>>       #define CONNCOUNT_SLOTS        256U
>>>    -#define CONNCOUNT_GC_MAX_NODES    8
>>> -#define MAX_KEYLEN        5
>>> +#define CONNCOUNT_GC_MAX_NODES        8
>>> +#define CONNCOUNT_GC_MAX_COLLECT    64
>>> +#define MAX_KEYLEN            5
>>>       /* we will save the tuples of all connections we care about */
>>>    struct nf_conncount_tuple {
>>> @@ -187,7 +188,7 @@ static int __nf_conncount_add(struct net *net,
>>>           /* check the saved connections */
>>>        list_for_each_entry_safe(conn, conn_n, &list->head, node) {
>>> -        if (collect > CONNCOUNT_GC_MAX_NODES)
>>> +        if (collect > CONNCOUNT_GC_MAX_COLLECT)
>>>                break;
>>>               found = find_or_evict(net, list, conn);
>>> @@ -316,7 +317,7 @@ static bool __nf_conncount_gc_list(struct net *net,
>>>            }
>>>               nf_ct_put(found_ct);
>>> -        if (collected > CONNCOUNT_GC_MAX_NODES)
>>> +        if (collected > CONNCOUNT_GC_MAX_COLLECT)
>>>                break;
>>>        }
>>
>>
>

-- 
regards,
Alexandra.

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

[Florian Westphal]

Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> After the optimization to only perform one GC per jiffy, a new problem
> was introduced. If more than 8 new connections are tracked per jiffy the
> list won't be cleaned up fast enough possibly reaching the limit
> wrongly.
> 
> In order to prevent this issue, increase the clean up limit to 64
> connections so it is easier for conncount to keep up with the new
> connections tracked per jiffy rate.

But that doesn't solve the issue, no?
Now its the same as before, just with 64 instead of 8.

I think that more work is needed.

>  /* we will save the tuples of all connections we care about */
>  struct nf_conncount_tuple {
> @@ -187,7 +188,7 @@ static int __nf_conncount_add(struct net *net,
>  
>  	/* check the saved connections */
>  	list_for_each_entry_safe(conn, conn_n, &list->head, node) {
> -		if (collect > CONNCOUNT_GC_MAX_NODES)
> +		if (collect > CONNCOUNT_GC_MAX_COLLECT)
>  			break;

I see several options.
One idea that comes to mind:

1. In nf_conncount_list, add "unsigned int scanned".
2. in __nf_conncount_add, move alive elements to the tail.
3. For each alive element, increment ->scanned.
4. break if scanned >= list->count.
5. only set last_gc if "->scanned >= list->count" (and set scanned to 0).

Before this only-one-gc-run-per-jiffy we always collected for each new
tracked entry, and hence we never had the "fills up" problem.

Maybe it would be possible to also apply this scheme to gc_list()
helper.

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

[Fernando Fernandez Mancera]

On 12/16/25 2:38 PM, Florian Westphal wrote:
> Fernando Fernandez Mancera <fmancera@suse.de> wrote:
>> After the optimization to only perform one GC per jiffy, a new problem
>> was introduced. If more than 8 new connections are tracked per jiffy the
>> list won't be cleaned up fast enough possibly reaching the limit
>> wrongly.
>>
>> In order to prevent this issue, increase the clean up limit to 64
>> connections so it is easier for conncount to keep up with the new
>> connections tracked per jiffy rate.
> 
> But that doesn't solve the issue, no?
> Now its the same as before, just with 64 instead of 8.
> 
> I think that more work is needed.
> 
>>   /* we will save the tuples of all connections we care about */
>>   struct nf_conncount_tuple {
>> @@ -187,7 +188,7 @@ static int __nf_conncount_add(struct net *net,
>>   
>>   	/* check the saved connections */
>>   	list_for_each_entry_safe(conn, conn_n, &list->head, node) {
>> -		if (collect > CONNCOUNT_GC_MAX_NODES)
>> +		if (collect > CONNCOUNT_GC_MAX_COLLECT)
>>   			break;
> 
> I see several options.
> One idea that comes to mind:
> 
> 1. In nf_conncount_list, add "unsigned int scanned".
> 2. in __nf_conncount_add, move alive elements to the tail.
> 3. For each alive element, increment ->scanned.
> 4. break if scanned >= list->count.
> 5. only set last_gc if "->scanned >= list->count" (and set scanned to 0).
> 

Hi Florian,

This sounds quite expensive to me. What about the following solution?

1. In nf_conncount_list, add "unsigned int last_gc_count"
2. In __nf_connncount_add the optimization would look like this:

	if ((u32)jiffies == list->last_gc && (list->count - 
list->last_gc_count) >= CONNCOUNT_GC_MAX_NODES - 1)
	goto add_new_node;

3. After gc, we update the list->last_gc_count.

This way we make sure the optimization is not done if 7 or more 
connections were added to the list. It should ensure that the list does 
not fill up. For better optimization, we can increase the number to 64 
as I proposed. The solution you proposed works too but I am worried that 
it will trigger a CPU lockup for a big amount of connections..

What do you think?

> Before this only-one-gc-run-per-jiffy we always collected for each new
> tracked entry, and hence we never had the "fills up" problem.
> 
> Maybe it would be possible to also apply this scheme to gc_list()
> helper.

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

[Florian Westphal]

Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> This sounds quite expensive to me. What about the following solution?
> 
> 1. In nf_conncount_list, add "unsigned int last_gc_count"
> 2. In __nf_connncount_add the optimization would look like this:
> 
> 	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.

> 3. After gc, we update the list->last_gc_count.
> 
> This way we make sure the optimization is not done if 7 or more connections
> were added to the list.

How many entries could be expected per seconds?  I think "tens of
thousands" is possible. If not, then just increasing the GC_MAX_NODES
would work.

If we can't make this work, no choice but to add a destructor callback
to conntrack... I very much dislike that idea.

> It should ensure that the list does not fill up. For
> better optimization, we can increase the number to 64 as I proposed. The
> solution you proposed works too but I am worried that it will trigger a CPU
> lockup for a big amount of connections..

You could add "start = jiffies" and break on "jiffies != start",
which would split the gc over multiple add requests.

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

[Fernando Fernandez Mancera]

On 12/16/25 4:25 PM, Florian Westphal wrote:
> Fernando Fernandez Mancera <fmancera@suse.de> wrote:
>> This sounds quite expensive to me. What about the following solution?
>>
>> 1. In nf_conncount_list, add "unsigned int last_gc_count"
>> 2. In __nf_connncount_add the optimization would look like this:
>>
>> 	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.

Also, it makes sense to start from the first element always as I guess 
the longer the connection has been opened the more likely is that is 
about to close.

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.

>> 3. After gc, we update the list->last_gc_count.
>>
>> This way we make sure the optimization is not done if 7 or more connections
>> were added to the list.
> 
> How many entries could be expected per seconds?  I think "tens of
> thousands" is possible. If not, then just increasing the GC_MAX_NODES
> would work.
> 

Yes that is right. FWIW, I believe that if we match the amount in 
netdev_budget we should be fine. But that seems like overkill to me.

> If we can't make this work, no choice but to add a destructor callback
> to conntrack... I very much dislike that idea.
> 

Yes, I do not like that neither.

>> It should ensure that the list does not fill up. For
>> better optimization, we can increase the number to 64 as I proposed. The
>> solution you proposed works too but I am worried that it will trigger a CPU
>> lockup for a big amount of connections..
> 
> You could add "start = jiffies" and break on "jiffies != start",
> which would split the gc over multiple add requests.

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

[Florian Westphal]

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.