|
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@xxxxxxxxxx/
>
> 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@xxxxxx>
|
