Re: [PATCH net 0/8] IPVS fixes for net

[Julian Anastasov <ja@ssi.bg>]

	Hello,

On Tue, 5 May 2026, Pablo Neira Ayuso wrote:

> Hi,
> 
> The following batch contains IPVS fixes for net to address issues
> from the latest net-next pull request.
> 
> Julian Anastasov made the following summary:
> 
> 1-3) Fixes for the recently added resizable hash tables
>  
> 4) dest from trash can be leaked if ip_vs_start_estimator() fails
>  
> 5) fixed races and locking for the estimation kthreads
>  
> 6) fix for wrong roundup_pow_of_two() usage in the resizable hash
>    tables
>  
> 7-8) v2 of the changes from Waiman Long to properly guard against
>   the housekeeping_cpumask() updates:
>  
>   https://lore.kernel.org/netfilter-devel/20260331165015.2777765-1-longman@redhat.com/
>  
>   I added missing Fixes tag. The original description:
>  
>   Since commit 041ee6f3727a ("kthread: Rely on HK_TYPE_DOMAIN for preferred
>   affinity management"), the HK_TYPE_KTHREAD housekeeping cpumask may no
>   longer be correct in showing the actual CPU affinity of kthreads that
>   have no predefined CPU affinity. As the ipvs networking code is still
>   using HK_TYPE_KTHREAD, we need to make HK_TYPE_KTHREAD reflect the
>   reality.
>  
>   This patch series makes HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
>   and uses RCU to protect access to the HK_TYPE_KTHREAD housekeeping
>   cpumask.
> 
> Julian plans to post a nf-next patch to limit the connections by using
> "conn_max" sysctl. With Simon Horman, they agreed that this is an old
> problem that we do not have a limit of connections and it is not a
> stopper for this patchset.
> 
> Please, pull these changes from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git nf-26-05-05
> 
> Thanks.
> 
> ----------------------------------------------------------------
> 
> The following changes since commit bd3a4795d5744f59a1f485379f1303e5e606f377:
> 
>   selftests: tls: add test for data loss on small pipe (2026-05-02 18:27:14 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-26-05-05
> 
> for you to fetch changes up to 8f78b749f3da0f43990490b4c1193b5ede3eec0a:
> 
>   sched/isolation: Make HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN (2026-05-05 01:52:55 +0200)
> 
> ----------------------------------------------------------------
> netfilter pull request 26-05-05
> 
> ----------------------------------------------------------------
> Julian Anastasov (6):
>       ipvs: fixes for the new ip_vs_status info
>       ipvs: fix races around the conn_lfactor and svc_lfactor sysctl vars
>       ipvs: fix the spin_lock usage for RT build
>       ipvs: do not leak dest after get from dest trash
>       ipvs: fix races around est_mutex and est_cpulist
>       ipvs: fix shift-out-of-bounds in ip_vs_rht_desired_size
> 
> Waiman Long (2):
>       ipvs: Guard access of HK_TYPE_KTHREAD cpumask with RCU
>       sched/isolation: Make HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> 
>  include/linux/sched/isolation.h |   6 +-
>  include/net/ip_vs.h             |  31 ++++++--
>  net/netfilter/ipvs/ip_vs_conn.c |  76 ++++++++++---------
>  net/netfilter/ipvs/ip_vs_core.c |   2 +-
>  net/netfilter/ipvs/ip_vs_ctl.c  | 164 +++++++++++++++++++++++++++++-----------
>  net/netfilter/ipvs/ip_vs_est.c  |  83 +++++++++++---------
>  6 files changed, 241 insertions(+), 121 deletions(-)

	Here are some comments after the last review from
Sashiko:

https://sashiko.dev/#/patchset/20260505001648.360569-1-pablo%40netfilter.org

Patch 1:
- while ip_vs_dst_event() should loop and ensure all dev
references are released, single change of svc_table_changes
does not indicate the old references are dropped by ip_vs_flush() or
ip_vs_del_service(). I'll post new change to abort the loop
when we are sure the services are at least once released.

Patch 5:
- after executing ip_vs_est_calc_phase(), data can
remain only for kt0 because all estimators are stopped,
unlinked and the kt data structures for kt > 0 are empty
and as result freed and the kthread tasks stopped (which
happens early). After this, kt 0 calls
ip_vs_est_drain_temp_list() as part of its loop,
so it will eventually call ip_vs_est_add_kthread()
and ip_vs_est_reload_start() to request kthread tasks
to be started if data for new kthreads are created.
So, I don't see problem here.

Patch 6:
- we will add conn_max sysctl soon

Patch 7 and 8:
- I can not decide how valid are the concerns in the review.

Regards

--
Julian Anastasov <ja@ssi.bg>