netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Antonio Quartulli <antonio@openvpn.net>
Cc: netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Donald Hunter <donald.hunter@gmail.com>,
	Shuah Khan <shuah@kernel.org>,
	ryazanov.s.a@gmail.com, Andrew Lunn <andrew+netdev@lunn.ch>,
	Simon Horman <horms@kernel.org>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	Xiao Liang <shaw.leon@gmail.com>
Subject: Re: [PATCH v21 18/24] ovpn: add support for peer floating
Date: Tue, 4 Mar 2025 19:37:18 +0100	[thread overview]
Message-ID: <Z8dIXjwZ3QmiEcd-@hog> (raw)
In-Reply-To: <20250304-b4-ovpn-tmp-v21-18-d3cbb74bb581@openvpn.net>

2025-03-04, 01:33:48 +0100, Antonio Quartulli wrote:
> A peer connected via UDP may change its IP address without reconnecting
> (float).

Should that trigger a reset of the peer->dst_cache? And same when
userspace updates the remote address? Otherwise it seems we could be
stuck with a cached dst that cannot reach the peer.


> +void ovpn_peer_endpoints_update(struct ovpn_peer *peer, struct sk_buff *skb)
> +{
> +	struct hlist_nulls_head *nhead;
> +	struct sockaddr_storage ss;
> +	const u8 *local_ip = NULL;
> +	struct sockaddr_in6 *sa6;
> +	struct sockaddr_in *sa;
> +	struct ovpn_bind *bind;
> +	size_t salen = 0;
> +
> +	spin_lock_bh(&peer->lock);
> +	bind = rcu_dereference_protected(peer->bind,
> +					 lockdep_is_held(&peer->lock));
> +	if (unlikely(!bind))
> +		goto unlock;
> +
> +	switch (skb->protocol) {
> +	case htons(ETH_P_IP):
> +		/* float check */
> +		if (unlikely(!ovpn_bind_skb_src_match(bind, skb))) {
> +			if (bind->remote.in4.sin_family == AF_INET)
> +				local_ip = (u8 *)&bind->local;

If I'm reading this correctly, we always reuse the existing local
address when we have to re-create the bind, even if it doesn't match
the skb? The "local endpoint update" chunk below is doing that, but
only if we're keeping the same remote? It'll get updated the next time
we receive a packet and call ovpn_peer_endpoints_update.

That might irritate the RPF check on the other side, if we still use
our "old" source to talk to the new dest?

> +			sa = (struct sockaddr_in *)&ss;
> +			sa->sin_family = AF_INET;
> +			sa->sin_addr.s_addr = ip_hdr(skb)->saddr;
> +			sa->sin_port = udp_hdr(skb)->source;
> +			salen = sizeof(*sa);
> +			break;
> +		}
> +
> +		/* local endpoint update */
> +		if (unlikely(bind->local.ipv4.s_addr != ip_hdr(skb)->daddr)) {
> +			net_dbg_ratelimited("%s: learning local IPv4 for peer %d (%pI4 -> %pI4)\n",
> +					    netdev_name(peer->ovpn->dev),
> +					    peer->id, &bind->local.ipv4.s_addr,
> +					    &ip_hdr(skb)->daddr);
> +			bind->local.ipv4.s_addr = ip_hdr(skb)->daddr;
> +		}
> +		break;

[...]
> +	if (peer->ovpn->mode == OVPN_MODE_MP) {
> +		spin_lock_bh(&peer->ovpn->lock);
> +		spin_lock_bh(&peer->lock);
> +		bind = rcu_dereference_protected(peer->bind,
> +						 lockdep_is_held(&peer->lock));
> +		if (unlikely(!bind)) {
> +			spin_unlock_bh(&peer->lock);
> +			spin_unlock_bh(&peer->ovpn->lock);
> +			return;
> +		}
> +
> +		/* his function may be invoked concurrently, therefore another

typo:
                   ^ This


[...]
> -/* variable name __tbl2 needs to be different from __tbl1
> - * in the macro below to avoid confusing clang
> - */
> -#define ovpn_get_hash_slot(_tbl, _key, _key_len) ({	\
> -	typeof(_tbl) *__tbl2 = &(_tbl);			\
> -	jhash(_key, _key_len, 0) % HASH_SIZE(*__tbl2);	\
> -})
> -
> -#define ovpn_get_hash_head(_tbl, _key, _key_len) ({		\
> -	typeof(_tbl) *__tbl1 = &(_tbl);				\
> -	&(*__tbl1)[ovpn_get_hash_slot(*__tbl1, _key, _key_len)];\
> -})
> -
>  /**
>   * ovpn_peer_get_by_vpn_addr4 - retrieve peer by its VPN IPv4 address
>   * @ovpn: the openvpn instance to search
> @@ -522,51 +694,6 @@ static void ovpn_peer_remove(struct ovpn_peer *peer,
>  	llist_add(&peer->release_entry, release_list);
>  }
>  
> -/**
> - * ovpn_peer_update_local_endpoint - update local endpoint for peer
> - * @peer: peer to update the endpoint for
> - * @skb: incoming packet to retrieve the destination address (local) from
> - */
> -void ovpn_peer_update_local_endpoint(struct ovpn_peer *peer,
> -				     struct sk_buff *skb)
> -{
> -	struct ovpn_bind *bind;
> -
> -	rcu_read_lock();
> -	bind = rcu_dereference(peer->bind);
> -	if (unlikely(!bind))
> -		goto unlock;
> -
> -	spin_lock_bh(&peer->lock);
> -	switch (skb->protocol) {
> -	case htons(ETH_P_IP):
> -		if (unlikely(bind->local.ipv4.s_addr != ip_hdr(skb)->daddr)) {
> -			net_dbg_ratelimited("%s: learning local IPv4 for peer %d (%pI4 -> %pI4)\n",
> -					    netdev_name(peer->ovpn->dev),
> -					    peer->id, &bind->local.ipv4.s_addr,
> -					    &ip_hdr(skb)->daddr);
> -			bind->local.ipv4.s_addr = ip_hdr(skb)->daddr;
> -		}
> -		break;
> -	case htons(ETH_P_IPV6):
> -		if (unlikely(!ipv6_addr_equal(&bind->local.ipv6,
> -					      &ipv6_hdr(skb)->daddr))) {
> -			net_dbg_ratelimited("%s: learning local IPv6 for peer %d (%pI6c -> %pI6c\n",
> -					    netdev_name(peer->ovpn->dev),
> -					    peer->id, &bind->local.ipv6,
> -					    &ipv6_hdr(skb)->daddr);
> -			bind->local.ipv6 = ipv6_hdr(skb)->daddr;
> -		}
> -		break;
> -	default:
> -		break;
> -	}
> -	spin_unlock_bh(&peer->lock);
> -
> -unlock:
> -	rcu_read_unlock();
> -}

I guess you could squash this and the previous patch into one to
reduce the churn (and get a little bit closer to the 15-patch limit :))

-- 
Sabrina

  reply	other threads:[~2025-03-04 18:37 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04  0:33 [PATCH v21 00/24] Introducing OpenVPN Data Channel Offload Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 01/24] net: introduce OpenVPN Data Channel Offload (ovpn) Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 02/24] ovpn: add basic netlink support Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 03/24] ovpn: add basic interface creation/destruction/management routines Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 04/24] ovpn: keep carrier always on for MP interfaces Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 05/24] ovpn: introduce the ovpn_peer object Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 06/24] ovpn: introduce the ovpn_socket object Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 07/24] ovpn: implement basic TX path (UDP) Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 08/24] ovpn: implement basic RX " Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 09/24] ovpn: implement packet processing Antonio Quartulli
2025-03-04 19:02   ` Sabrina Dubroca
2025-03-04 23:35     ` Antonio Quartulli
2025-03-05 10:06       ` Sabrina Dubroca
2025-03-04  0:33 ` [PATCH v21 10/24] ovpn: store tunnel and transport statistics Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 11/24] ovpn: implement TCP transport Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 12/24] skb: implement skb_send_sock_locked_with_flags() Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 13/24] ovpn: add support for MSG_NOSIGNAL in tcp_sendmsg Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 14/24] ovpn: implement multi-peer support Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 15/24] ovpn: implement peer lookup logic Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 16/24] ovpn: implement keepalive mechanism Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 17/24] ovpn: add support for updating local UDP endpoint Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 18/24] ovpn: add support for peer floating Antonio Quartulli
2025-03-04 18:37   ` Sabrina Dubroca [this message]
2025-03-04 23:19     ` Antonio Quartulli
2025-03-05  0:19       ` Antonio Quartulli
2025-03-05 11:20       ` Sabrina Dubroca
2025-03-05 13:14         ` Antonio Quartulli
2025-03-05 16:56           ` Sabrina Dubroca
2025-03-06 10:02             ` Antonio Quartulli
2025-03-07 10:12               ` Sabrina Dubroca
2025-03-10 12:57                 ` Antonio Quartulli
2025-03-10 22:32                   ` Sabrina Dubroca
2025-03-04  0:33 ` [PATCH v21 19/24] ovpn: implement peer add/get/dump/delete via netlink Antonio Quartulli
2025-03-04 14:35   ` Sabrina Dubroca
2025-03-04 21:42     ` Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 20/24] ovpn: implement key add/get/del/swap " Antonio Quartulli
2025-03-04 12:00   ` Sabrina Dubroca
2025-03-04 12:11     ` Antonio Quartulli
2025-03-04 23:09       ` Sabrina Dubroca
2025-03-05  1:00         ` Antonio Quartulli
2025-03-05 10:11           ` Sabrina Dubroca
2025-03-05 13:17             ` Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 21/24] ovpn: kill key and notify userspace in case of IV exhaustion Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 22/24] ovpn: notify userspace when a peer is deleted Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 23/24] ovpn: add basic ethtool support Antonio Quartulli
2025-03-04  0:33 ` [PATCH v21 24/24] testing/selftests: add test tool and scripts for ovpn module Antonio Quartulli

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=Z8dIXjwZ3QmiEcd-@hog \
    --to=sd@queasysnail.net \
    --cc=andrew+netdev@lunn.ch \
    --cc=antonio@openvpn.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ryazanov.s.a@gmail.com \
    --cc=shaw.leon@gmail.com \
    --cc=shuah@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).