From: Sabrina Dubroca <sd@queasysnail.net>
To: Antonio Quartulli <antonio@openvpn.net>
Cc: netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
Sergey Ryazanov <ryazanov.s.a@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>, Andrew Lunn <andrew@lunn.ch>,
Esben Haabendal <esben@geanix.com>
Subject: Re: [PATCH net-next v3 15/24] ovpn: implement peer lookup logic
Date: Tue, 28 May 2024 18:42:16 +0200 [thread overview]
Message-ID: <ZlYJaIvXY3nuNd98@hog> (raw)
In-Reply-To: <20240506011637.27272-16-antonio@openvpn.net>
2024-05-06, 03:16:28 +0200, Antonio Quartulli wrote:
> +static struct in6_addr ovpn_nexthop_from_skb6(struct sk_buff *skb)
> +{
> + struct rt6_info *rt = (struct rt6_info *)skb_rtable(skb);
skb_rt6_info?
> +
> + if (!rt || !(rt->rt6i_flags & RTF_GATEWAY))
> + return ipv6_hdr(skb)->daddr;
> +
> + return rt->rt6i_gateway;
> +}
> +
> +/**
> + * ovpn_peer_get_by_vpn_addr4 - retrieve peer by its VPN IPv4 address
> + * @head: list head to search
> + * @addr: VPN IPv4 to use as search key
> + *
> + * Return: the peer if found or NULL otherwise
The doc for all those ovpn_peer_get_* functions could indicate that on
success, a reference on the peer is held.
[...]
> +static struct ovpn_peer *ovpn_peer_get_by_vpn_addr6(struct hlist_head *head,
> + struct in6_addr *addr)
> +{
> + struct ovpn_peer *tmp, *peer = NULL;
> + int i;
> +
> + rcu_read_lock();
> + hlist_for_each_entry_rcu(tmp, head, hash_entry_addr6) {
> + for (i = 0; i < 4; i++) {
> + if (addr->s6_addr32[i] !=
> + tmp->vpn_addrs.ipv6.s6_addr32[i])
> + continue;
> + }
ipv6_addr_equal
[...]
> + default:
> + return NULL;
> + }
> +
> + index = ovpn_peer_index(ovpn->peers.by_transp_addr, &ss, sa_len);
> + head = &ovpn->peers.by_transp_addr[index];
Maybe worth adding a get_bucket helper (with a better name :)) instead
of ovpn_peer_index, since all uses of ovpn_peer_index are followed by
a "head = TBL[index]" (or direct use in some hlist iterator), but the
index itself is not used later on, only the bucket.
> +
> + rcu_read_lock();
> + hlist_for_each_entry_rcu(tmp, head, hash_entry_transp_addr) {
> + found = ovpn_peer_transp_match(tmp, &ss);
> + if (!found)
nit: call ovpn_peer_transp_match directly and drop the found variable
> + continue;
> +
> + if (!ovpn_peer_hold(tmp))
> + continue;
> +
> + peer = tmp;
> + break;
> + }
> + rcu_read_unlock();
>
> return peer;
> }
> @@ -303,10 +427,28 @@ static struct ovpn_peer *ovpn_peer_get_by_id_p2p(struct ovpn_struct *ovpn,
>
> struct ovpn_peer *ovpn_peer_get_by_id(struct ovpn_struct *ovpn, u32 peer_id)
> {
> - struct ovpn_peer *peer = NULL;
> + struct ovpn_peer *tmp, *peer = NULL;
> + struct hlist_head *head;
> + u32 index;
>
> if (ovpn->mode == OVPN_MODE_P2P)
> - peer = ovpn_peer_get_by_id_p2p(ovpn, peer_id);
> + return ovpn_peer_get_by_id_p2p(ovpn, peer_id);
> +
> + index = ovpn_peer_index(ovpn->peers.by_id, &peer_id, sizeof(peer_id));
> + head = &ovpn->peers.by_id[index];
> +
> + rcu_read_lock();
> + hlist_for_each_entry_rcu(tmp, head, hash_entry_id) {
> + if (tmp->id != peer_id)
> + continue;
> +
> + if (!ovpn_peer_hold(tmp))
> + continue;
Can there ever be multiple peers with the same id? (ie, is it worth
continuing the loop if this fails? the same question probably applies
to ovpn_peer_get_by_transp_addr as well)
> + peer = tmp;
> + break;
> + }
> + rcu_read_unlock();
>
> return peer;
> }
> @@ -328,6 +470,11 @@ struct ovpn_peer *ovpn_peer_get_by_dst(struct ovpn_struct *ovpn,
> struct sk_buff *skb)
> {
> struct ovpn_peer *tmp, *peer = NULL;
> + struct hlist_head *head;
> + sa_family_t sa_fam;
> + struct in6_addr addr6;
> + __be32 addr4;
> + u32 index;
>
> /* in P2P mode, no matter the destination, packets are always sent to
> * the single peer listening on the other side
> @@ -338,15 +485,123 @@ struct ovpn_peer *ovpn_peer_get_by_dst(struct ovpn_struct *ovpn,
> if (likely(tmp && ovpn_peer_hold(tmp)))
> peer = tmp;
> rcu_read_unlock();
> + return peer;
> + }
> +
> + sa_fam = skb_protocol_to_family(skb);
> +
> + switch (sa_fam) {
> + case AF_INET:
> + addr4 = ovpn_nexthop_from_skb4(skb);
> + index = ovpn_peer_index(ovpn->peers.by_vpn_addr, &addr4,
> + sizeof(addr4));
> + head = &ovpn->peers.by_vpn_addr[index];
> +
> + peer = ovpn_peer_get_by_vpn_addr4(head, &addr4);
> + break;
> + case AF_INET6:
> + addr6 = ovpn_nexthop_from_skb6(skb);
> + index = ovpn_peer_index(ovpn->peers.by_vpn_addr, &addr6,
> + sizeof(addr6));
> + head = &ovpn->peers.by_vpn_addr[index];
> +
> + peer = ovpn_peer_get_by_vpn_addr6(head, &addr6);
The index -> head -> peer code is identical in get_by_dst and
get_by_src, it could be stuffed into ovpn_peer_get_by_vpn_addr{4,6}.
> + break;
> }
>
> return peer;
> }
[snip the _rt4 variant, comments apply to both]
> +/**
> + * ovpn_nexthop_from_rt6 - look up the IPv6 nexthop for the given destination
I'm a bit confused by this talk about "destination" when those two
functions are then used with the source address from the packet, from
a function called "get_by_src".
> + * @ovpn: the private data representing the current VPN session
> + * @dst: the destination to be looked up
> + *
> + * Looks up in the IPv6 system routing table the IO of the nexthop to be used
"the IO"?
> + * to reach the destination passed as argument. IF no nexthop can be found, the
> + * destination itself is returned as it probably has to be used as nexthop.
> + *
> + * Return: the IP of the next hop if found or the dst itself otherwise
"the dst" tends to refer to a dst_entry, maybe "or @dst otherwise"?
(though I'm not sure that's valid kdoc)
(also for ovpn_nexthop_from_rt4)
> + */
> +static struct in6_addr ovpn_nexthop_from_rt6(struct ovpn_struct *ovpn,
> + struct in6_addr dst)
> +{
> +#if IS_ENABLED(CONFIG_IPV6)
> + struct dst_entry *entry;
> + struct rt6_info *rt;
> + struct flowi6 fl = {
> + .daddr = dst,
> + };
> +
> + entry = ipv6_stub->ipv6_dst_lookup_flow(dev_net(ovpn->dev), NULL, &fl,
> + NULL);
> + if (IS_ERR(entry)) {
> + net_dbg_ratelimited("%s: no route to host %pI6c\n", __func__,
> + &dst);
> + /* if we end up here this packet is probably going to be
> + * thrown away later
> + */
> + return dst;
> + }
> +
> + rt = container_of(entry, struct rt6_info, dst);
dst_rt6_info(entry)
> +
> + if (!(rt->rt6i_flags & RTF_GATEWAY))
> + goto out;
> +
> + dst = rt->rt6i_gateway;
> +out:
> + dst_release((struct dst_entry *)rt);
> +#endif
> + return dst;
> +}
> +
> struct ovpn_peer *ovpn_peer_get_by_src(struct ovpn_struct *ovpn,
> struct sk_buff *skb)
> {
> struct ovpn_peer *tmp, *peer = NULL;
> + struct hlist_head *head;
> + sa_family_t sa_fam;
> + struct in6_addr addr6;
> + __be32 addr4;
> + u32 index;
>
> /* in P2P mode, no matter the destination, packets are always sent to
> * the single peer listening on the other side
> @@ -357,6 +612,28 @@ struct ovpn_peer *ovpn_peer_get_by_src(struct ovpn_struct *ovpn,
> if (likely(tmp && ovpn_peer_hold(tmp)))
> peer = tmp;
> rcu_read_unlock();
> + return peer;
> + }
> +
> + sa_fam = skb_protocol_to_family(skb);
> +
> + switch (sa_fam) {
nit:
switch (skb_protocol_to_family(skb))
seems a bit more readable to me (also in ovpn_peer_get_by_dst) - and
saves you from reverse xmas tree complaints (sa_fam should have been
after addr6)
> + case AF_INET:
> + addr4 = ovpn_nexthop_from_rt4(ovpn, ip_hdr(skb)->saddr);
> + index = ovpn_peer_index(ovpn->peers.by_vpn_addr, &addr4,
> + sizeof(addr4));
> + head = &ovpn->peers.by_vpn_addr[index];
> +
> + peer = ovpn_peer_get_by_vpn_addr4(head, &addr4);
> + break;
> + case AF_INET6:
> + addr6 = ovpn_nexthop_from_rt6(ovpn, ipv6_hdr(skb)->saddr);
> + index = ovpn_peer_index(ovpn->peers.by_vpn_addr, &addr6,
> + sizeof(addr6));
> + head = &ovpn->peers.by_vpn_addr[index];
> +
> + peer = ovpn_peer_get_by_vpn_addr6(head, &addr6);
> + break;
> }
>
> return peer;
> --
> 2.43.2
>
>
--
Sabrina
next prev parent reply other threads:[~2024-05-28 16:42 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 1:16 [PATCH net-next v3 00/24] Introducing OpenVPN Data Channel Offload Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 01/24] netlink: add NLA_POLICY_MAX_LEN macro Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 02/24] net: introduce OpenVPN Data Channel Offload (ovpn) Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 03/24] ovpn: add basic netlink support Antonio Quartulli
2024-05-08 0:10 ` Jakub Kicinski
2024-05-08 7:42 ` Antonio Quartulli
2024-05-08 14:42 ` Sabrina Dubroca
2024-05-08 14:51 ` Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 04/24] ovpn: add basic interface creation/destruction/management routines Antonio Quartulli
2024-05-08 0:18 ` Jakub Kicinski
2024-05-08 7:53 ` Antonio Quartulli
2024-05-08 14:52 ` Sabrina Dubroca
2024-05-09 1:06 ` Jakub Kicinski
2024-05-09 8:25 ` Antonio Quartulli
2024-05-09 10:09 ` Sabrina Dubroca
2024-05-09 10:35 ` Antonio Quartulli
2024-05-09 12:16 ` Sabrina Dubroca
2024-05-09 13:25 ` Antonio Quartulli
2024-05-09 13:52 ` Sabrina Dubroca
2024-05-06 1:16 ` [PATCH net-next v3 05/24] ovpn: implement interface creation/destruction via netlink Antonio Quartulli
2024-05-08 0:21 ` Jakub Kicinski
2024-05-08 9:49 ` Antonio Quartulli
2024-05-09 1:09 ` Jakub Kicinski
2024-05-09 8:30 ` Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 06/24] ovpn: keep carrier always on Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 07/24] ovpn: introduce the ovpn_peer object Antonio Quartulli
2024-05-08 16:06 ` Sabrina Dubroca
2024-05-08 20:31 ` Antonio Quartulli
2024-05-09 13:04 ` Sabrina Dubroca
2024-05-09 13:24 ` Andrew Lunn
2024-05-10 18:57 ` Antonio Quartulli
2024-05-11 0:28 ` Jakub Kicinski
2024-05-09 13:44 ` Antonio Quartulli
2024-05-09 13:55 ` Andrew Lunn
2024-05-09 14:17 ` Sabrina Dubroca
2024-05-09 14:36 ` Antonio Quartulli
2024-05-09 14:53 ` Antonio Quartulli
2024-05-10 10:30 ` Sabrina Dubroca
2024-05-10 12:34 ` Antonio Quartulli
2024-05-10 14:11 ` Sabrina Dubroca
2024-05-13 10:09 ` Simon Horman
2024-05-13 10:53 ` Antonio Quartulli
2024-05-13 15:04 ` Simon Horman
2024-05-06 1:16 ` [PATCH net-next v3 08/24] ovpn: introduce the ovpn_socket object Antonio Quartulli
2024-05-08 17:10 ` Sabrina Dubroca
2024-05-08 20:38 ` Antonio Quartulli
2024-05-09 13:32 ` Sabrina Dubroca
2024-05-09 13:46 ` Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 09/24] ovpn: implement basic TX path (UDP) Antonio Quartulli
2024-05-10 13:01 ` Sabrina Dubroca
2024-05-10 13:39 ` Antonio Quartulli
2024-05-12 21:35 ` Sabrina Dubroca
2024-05-13 7:37 ` Antonio Quartulli
2024-05-13 9:36 ` Sabrina Dubroca
2024-05-13 9:47 ` Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 10/24] ovpn: implement basic RX " Antonio Quartulli
2024-05-10 13:45 ` Sabrina Dubroca
2024-05-10 14:41 ` Antonio Quartulli
2024-07-18 10:46 ` Sabrina Dubroca
2024-07-18 13:06 ` Antonio Quartulli
2024-07-18 13:11 ` Sabrina Dubroca
2024-07-18 13:27 ` Antonio Quartulli
2024-07-18 13:40 ` Sabrina Dubroca
2024-07-18 14:15 ` Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 11/24] ovpn: implement packet processing Antonio Quartulli
2024-05-12 8:46 ` Sabrina Dubroca
2024-05-13 7:14 ` Antonio Quartulli
2024-05-13 9:24 ` Sabrina Dubroca
2024-05-13 9:31 ` Antonio Quartulli
2024-05-22 14:08 ` Antonio Quartulli
2024-05-22 14:28 ` Andrew Lunn
2024-05-06 1:16 ` [PATCH net-next v3 12/24] ovpn: store tunnel and transport statistics Antonio Quartulli
2024-05-12 8:47 ` Sabrina Dubroca
2024-05-13 7:25 ` Antonio Quartulli
2024-05-13 9:19 ` Sabrina Dubroca
2024-05-13 9:33 ` Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 13/24] ovpn: implement TCP transport Antonio Quartulli
2024-05-13 13:37 ` Antonio Quartulli
2024-05-13 15:34 ` Jakub Kicinski
2024-05-13 14:50 ` Sabrina Dubroca
2024-05-13 22:20 ` Antonio Quartulli
2024-05-14 8:58 ` Sabrina Dubroca
2024-05-14 22:11 ` Antonio Quartulli
2024-05-15 10:19 ` Sabrina Dubroca
2024-05-15 12:54 ` Antonio Quartulli
2024-05-15 14:55 ` Sabrina Dubroca
2024-05-15 19:44 ` Antonio Quartulli
2024-05-15 20:35 ` Sabrina Dubroca
2024-05-15 20:39 ` Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 14/24] ovpn: implement multi-peer support Antonio Quartulli
2024-05-28 14:44 ` Sabrina Dubroca
2024-05-28 19:41 ` Antonio Quartulli
2024-05-29 15:16 ` Sabrina Dubroca
2024-05-29 20:15 ` Antonio Quartulli
2024-05-29 20:45 ` Sabrina Dubroca
2024-05-06 1:16 ` [PATCH net-next v3 15/24] ovpn: implement peer lookup logic Antonio Quartulli
2024-05-28 16:42 ` Sabrina Dubroca [this message]
2024-05-28 20:09 ` Antonio Quartulli
2024-05-29 16:42 ` Sabrina Dubroca
2024-05-29 20:19 ` Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 16/24] ovpn: implement keepalive mechanism Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 17/24] ovpn: add support for updating local UDP endpoint Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 18/24] ovpn: add support for peer floating Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 19/24] ovpn: implement peer add/dump/delete via netlink Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 20/24] ovpn: implement key add/del/swap " Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 21/24] ovpn: kill key and notify userspace in case of IV exhaustion Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 22/24] ovpn: notify userspace when a peer is deleted Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 23/24] ovpn: add basic ethtool support Antonio Quartulli
2024-05-06 1:16 ` [PATCH net-next v3 24/24] testing/selftest: add test tool and scripts for ovpn module Antonio Quartulli
2024-05-07 23:55 ` Jakub Kicinski
2024-05-08 9:51 ` Antonio Quartulli
2024-05-09 0:50 ` Jakub Kicinski
2024-05-09 8:40 ` Antonio Quartulli
2024-05-07 23:48 ` [PATCH net-next v3 00/24] Introducing OpenVPN Data Channel Offload Jakub Kicinski
2024-05-08 9:56 ` Antonio Quartulli
2024-05-09 0:53 ` Jakub Kicinski
2024-05-09 8:41 ` 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=ZlYJaIvXY3nuNd98@hog \
--to=sd@queasysnail.net \
--cc=andrew@lunn.ch \
--cc=antonio@openvpn.net \
--cc=edumazet@google.com \
--cc=esben@geanix.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ryazanov.s.a@gmail.com \
/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).