LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [PATCH v2 nf] ipvs: avoid possible loop in ip_vs_dst_event on resizi

To: Simon Horman <horms@xxxxxxxxxxxx>
Subject: Re: [PATCH v2 nf] ipvs: avoid possible loop in ip_vs_dst_event on resizing
Cc: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>, Florian Westphal <fw@xxxxxxxxx>, lvs-devel@xxxxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 8 May 2026 12:58:26 +0300 (EEST)
        Hello,

On Thu, 7 May 2026, Julian Anastasov wrote:

> Sashiko points out that unprivileged user can frequently
> call ip_vs_flush() or ip_vs_del_service() to trigger
> svc_table_changes updates that can lead to infinite loop
> in ip_vs_dst_event(). This can also happen if the user
> triggers frequent table resizing without deleting all
> services. We should also consider the possible effects
> if the user triggers many NETDEV_DOWN events.
> 
> One way to solve it is to hold svc_resize_sem in
> ip_vs_dst_event() but this can block the dev notifier
> during the whole resizing process.
> 
> Instead, use new rw_semaphore svc_replace_sem to protect just
> the svc_table replacement which is a short code section.
> Then hold svc_replace_sem in ip_vs_dst_event() to serialize
> with replacing the svc_table. As result, loop is avoided
> as there is no need to repeat the table walking from the
> start. By this way changes in svc_table_changes can happen
> only when all services are removed and all dev references
> dropped which allows us to abort the table walking.
> 
> As IP_VS_WORK_SVC_NORESIZE is the flag used to stop the
> svc_resize_work under service_mutex, we should check only
> this flag often but not while under service_mutex.
> 
> Link: 
> https://sashiko.dev/#/patchset/20260505001648.360569-1-pablo%40netfilter.org
> Fixes: 840aac3d900d ("ipvs: use resizable hash table for services")
> Signed-off-by: Julian Anastasov <ja@xxxxxx>

        There is a way to remove the trylock in svc_resize_work,
will send v3 later today.

pw-bot: changes-requested

Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>