All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: fw@strlen.de
Cc: Jakub Kicinski <kuba@kernel.org>,
	netfilter-devel@vger.kernel.org, pabeni@redhat.com,
	davem@davemloft.net, edumazet@google.com, netdev@vger.kernel.org,
	pablo@netfilter.org
Subject: Re: [net-next,4/9] ipvs: do not keep dest_dst after dest is removed
Date: Wed, 25 Feb 2026 19:41:24 -0800	[thread overview]
Message-ID: <20260226034124.1806970-1-kuba@kernel.org> (raw)
In-Reply-To: <20260224205048.4718-5-fw@strlen.de>

This is an AI-generated review of your patch. The human sending this
email says "FYI"

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ipvs: do not keep dest_dst after dest is removed

Before now dest->dest_dst is not released when server is moved into
dest_trash list after removal. As result, we can keep dst/dev
references for long time without actively using them. It is better to
avoid walking the dest_trash list when ip_vs_dst_event() receives dev
events. So, make sure we do not hold dev references in dest_trash
list. As packets can be flying while server is being removed, check
the IP_VS_DEST_F_AVAILABLE flag in slow path to ensure we do not save
new dev references to removed servers.

> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 2ef1f99dada6..7c0e2d9b5b98 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c

[ ... ]

> diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
> index 4389bfe3050d..394b5b5f2ccd 100644
> --- a/net/netfilter/ipvs/ip_vs_xmit.c
> +++ b/net/netfilter/ipvs/ip_vs_xmit.c
> @@ -336,9 +336,11 @@ __ip_vs_get_out_rt(struct netns_ipvs *ipvs, int skb_af, struct sk_buff *skb,
>  				goto err_unreach;
>  			}
>  			/* It is forbidden to attach dest->dest_dst if
> -			 * device is going down.
> +			 * device is going down or if server is removed and
> +			 * stored in dest_trash.
>  			 */
> -			if (!rt_dev_is_down(dst_dev_rcu(&rt->dst)))
> +			if (!rt_dev_is_down(dst_dev_rcu(&rt->dst)) &&
> +			    dest->flags & IP_VS_DEST_F_AVAILABLE)
>  				__ip_vs_dst_set(dest, dest_dst, &rt->dst, 0);

Should this be wrapped in parentheses?

In C operator precedence, the logical AND (&&) binds more tightly than
the bitwise AND (&). The expression here parses as:

    (!rt_dev_is_down(...) && dest->flags) & IP_VS_DEST_F_AVAILABLE

This works correctly only because IP_VS_DEST_F_AVAILABLE is 0x0001, and
the logical AND produces 0 or 1, so the bitwise AND with 0x0001 still
produces the expected result.

Every other check of IP_VS_DEST_F_AVAILABLE in the IPVS codebase wraps
the bitwise operation in parentheses. For example:

net/netfilter/ipvs/ip_vs_core.c:ip_vs_out():
    if (likely(dest && (dest->flags & IP_VS_DEST_F_AVAILABLE))) {
        ...
    }

net/netfilter/ipvs/ip_vs_conn.c:ip_vs_conn_fill_param_sync():
    if (unlikely(dest && !(dest->flags & IP_VS_DEST_F_AVAILABLE))) {
        ...
    }

Would it be clearer to write this as:

    if (!rt_dev_is_down(dst_dev_rcu(&rt->dst)) &&
        (dest->flags & IP_VS_DEST_F_AVAILABLE))

>  			else
>  				noref = 0;

[ ... ]

> @@ -513,9 +515,11 @@ __ip_vs_get_out_rt_v6(struct netns_ipvs *ipvs, int skb_af, struct sk_buff *skb,
>  			rt = dst_rt6_info(dst);
>  			cookie = rt6_get_cookie(rt);
>  			/* It is forbidden to attach dest->dest_dst if
> -			 * device is going down.
> +			 * device is going down or if server is removed and
> +			 * stored in dest_trash.
>  			 */
> -			if (!rt_dev_is_down(dst_dev_rcu(&rt->dst)))
> +			if (!rt_dev_is_down(dst_dev_rcu(&rt->dst)) &&
> +			    dest->flags & IP_VS_DEST_F_AVAILABLE)
>  				__ip_vs_dst_set(dest, dest_dst, &rt->dst, cookie);

Same question here in __ip_vs_get_out_rt_v6().

  reply	other threads:[~2026-02-26  3:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24 20:50 [PATCH net-next 0/9] netfilter: updates for net-next Florian Westphal
2026-02-24 20:50 ` [PATCH net-next 1/9] ipvs: make ip_vs_svc_table and ip_vs_svc_fwm_table per netns Florian Westphal
2026-02-26  3:41   ` [net-next,1/9] " Jakub Kicinski
2026-02-26 19:19     ` Julian Anastasov
2026-02-24 20:50 ` [PATCH net-next 2/9] ipvs: some service readers can use RCU Florian Westphal
2026-02-24 20:50 ` [PATCH net-next 3/9] ipvs: use single svc table Florian Westphal
2026-02-26  3:41   ` [net-next,3/9] " Jakub Kicinski
2026-02-24 20:50 ` [PATCH net-next 4/9] ipvs: do not keep dest_dst after dest is removed Florian Westphal
2026-02-26  3:41   ` Jakub Kicinski [this message]
2026-02-26  3:44     ` [net-next,4/9] " Jakub Kicinski
2026-02-24 20:50 ` [PATCH net-next 5/9] ipvs: use more counters to avoid service lookups Florian Westphal
2026-02-24 20:50 ` [PATCH net-next 6/9] ipvs: no_cport and dropentry counters can be per-net Florian Westphal
2026-02-24 20:50 ` [PATCH net-next 7/9] netfilter: nft_set_rbtree: don't disable bh when acquiring tree lock Florian Westphal
2026-02-24 20:50 ` [PATCH net-next 8/9] netfilter: nf_tables: drop obsolete EXPORT_SYMBOLs Florian Westphal
2026-02-24 20:50 ` [PATCH net-next 9/9] netfilter: nf_tables: remove register tracking infrastructure Florian Westphal
2026-02-26  3:50 ` [PATCH net-next 0/9] netfilter: updates for net-next patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260226034124.1806970-1-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.