From: Antonio Quartulli <antonio@openvpn.net>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: 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@lunn.ch>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next v11 15/23] ovpn: implement keepalive mechanism
Date: Tue, 12 Nov 2024 14:20:45 +0100 [thread overview]
Message-ID: <189dbeea-127a-47e8-84f8-c8cf1cc03536@openvpn.net> (raw)
In-Reply-To: <ZypfnyfToF1b6YAZ@hog>
On 05/11/2024 19:10, Sabrina Dubroca wrote:
> 2024-10-29, 11:47:28 +0100, Antonio Quartulli wrote:
>> @@ -105,6 +132,9 @@ void ovpn_decrypt_post(void *data, int ret)
>> goto drop;
>> }
>>
>> + /* keep track of last received authenticated packet for keepalive */
>> + peer->last_recv = ktime_get_real_seconds();
>
> It doesn't look like we're locking the peer here so that should be a
> WRITE_ONCE() (and READ_ONCE(peer->last_recv) for all reads).
Is that because last_recv is 64 bit long (and might be more than one
word on certain architectures)?
I don't remember having to do so for reading/writing 32 bit long integers.
I presume we need a WRITE_ONCE also upon initialization in
ovpn_peer_keepalive_set() right?
We still want to coordinate that with other reads/writes.
>
>> +
>> /* point to encapsulated IP packet */
>> __skb_pull(skb, payload_offset);
>>
>> @@ -121,6 +151,12 @@ void ovpn_decrypt_post(void *data, int ret)
>> goto drop;
>> }
>>
>> + if (ovpn_is_keepalive(skb)) {
>> + net_dbg_ratelimited("%s: ping received from peer %u\n",
>> + peer->ovpn->dev->name, peer->id);
>> + goto drop;
>
> To help with debugging connectivity issues, maybe keepalives shouldn't
> be counted as drops? (consume_skb instead of kfree_skb, and not
> incrementing rx_dropped)
> The packet was successfully received and did all it had to do.
you're absolutely right. Will change that.
>
>> + }
>> +
>> net_info_ratelimited("%s: unsupported protocol received from peer %u\n",
>> peer->ovpn->dev->name, peer->id);
>> goto drop;
>> @@ -221,6 +257,10 @@ void ovpn_encrypt_post(void *data, int ret)
>> /* no transport configured yet */
>> goto err;
>> }
>> +
>> + /* keep track of last sent packet for keepalive */
>> + peer->last_sent = ktime_get_real_seconds();
>
> And another WRITE_ONCE() here (also paired with READ_ONCE() on the
> read side).
Yap
>
>
>> +static int ovpn_peer_del_nolock(struct ovpn_peer *peer,
>> + enum ovpn_del_peer_reason reason)
>> +{
>> + switch (peer->ovpn->mode) {
>> + case OVPN_MODE_MP:
>
> I think it would be nice to add
>
> lockdep_assert_held(&peer->ovpn->peers->lock);
>
>> + return ovpn_peer_del_mp(peer, reason);
>> + case OVPN_MODE_P2P:
>
> and here
>
> lockdep_assert_held(&peer->ovpn->lock);
Yeah, good idea.
__must_hold() can't work here, so lockdep_assert_held is definitely the
way to go.
>
> (I had to check that ovpn_peer_del_nolock is indeed called with those
> locks held since they're taken by ovpn_peer_keepalive_work_{mp,p2p},
> adding these assertions would make it clear that ovpn_peer_del_nolock
> is not an unsafe version of ovpn_peer_del)
Right, it makes sense.
>
>> + return ovpn_peer_del_p2p(peer, reason);
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>> +}
>> +
>> /**
>> * ovpn_peers_free - free all peers in the instance
>> * @ovpn: the instance whose peers should be released
>> @@ -830,3 +871,150 @@ void ovpn_peers_free(struct ovpn_struct *ovpn)
>> ovpn_peer_unhash(peer, OVPN_DEL_PEER_REASON_TEARDOWN);
>> spin_unlock_bh(&ovpn->peers->lock);
>> }
>> +
>> +static time64_t ovpn_peer_keepalive_work_single(struct ovpn_peer *peer,
>> + time64_t now)
>> +{
>> + time64_t next_run1, next_run2, delta;
>> + unsigned long timeout, interval;
>> + bool expired;
>> +
>> + spin_lock_bh(&peer->lock);
>> + /* we expect both timers to be configured at the same time,
>> + * therefore bail out if either is not set
>> + */
>> + if (!peer->keepalive_timeout || !peer->keepalive_interval) {
>> + spin_unlock_bh(&peer->lock);
>> + return 0;
>> + }
>> +
>> + /* check for peer timeout */
>> + expired = false;
>> + timeout = peer->keepalive_timeout;
>> + delta = now - peer->last_recv;
>
> I'm not sure that's always > 0 if we finish decrypting a packet just
> as the workqueue starts:
>
> ovpn_peer_keepalive_work
> now = ...
>
> ovpn_decrypt_post
> peer->last_recv = ...
>
> ovpn_peer_keepalive_work_single
> delta: now < peer->last_recv
>
Yeah, there is nothing preventing this from happening...but is this
truly a problem? The math should still work, no?
However:
>
>
>> + if (delta < timeout) {
>> + peer->keepalive_recv_exp = now + timeout - delta;
>
> I'd shorten that to
>
> peer->keepalive_recv_exp = peer->last_recv + timeout;
>
> it's a bit more readable to my eyes and avoids risks of wrapping
> values.
>
> So I'd probably get rid of delta and go with:
>
> last_recv = READ_ONCE(peer->last_recv)
> if (now < last_recv + timeout) {
> peer->keepalive_recv_exp = last_recv + timeout;
> next_run1 = peer->keepalive_recv_exp;
> } else if ...
>
>> + next_run1 = peer->keepalive_recv_exp;
>> + } else if (peer->keepalive_recv_exp > now) {
>> + next_run1 = peer->keepalive_recv_exp;
>> + } else {
>> + expired = true;
>> + }
I agree this is simpler to read and gets rid of some extra operations.
[note: I took inspiration from nat_keepalive_work_single() - it could be
simplified as well I guess]
>
> [...]
>> + /* check for peer keepalive */
>> + expired = false;
>> + interval = peer->keepalive_interval;
>> + delta = now - peer->last_sent;
>> + if (delta < interval) {
>> + peer->keepalive_xmit_exp = now + interval - delta;
>> + next_run2 = peer->keepalive_xmit_exp;
>
> and same here
Yeah, will change both. Thanks!
Regards,
--
Antonio Quartulli
OpenVPN Inc.
next prev parent reply other threads:[~2024-11-12 13:20 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 10:47 [PATCH net-next v11 00/23] Introducing OpenVPN Data Channel Offload Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 01/23] netlink: add NLA_POLICY_MAX_LEN macro Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 02/23] net: introduce OpenVPN Data Channel Offload (ovpn) Antonio Quartulli
2024-11-06 0:31 ` Sergey Ryazanov
2024-11-15 9:56 ` Antonio Quartulli
2024-11-19 1:49 ` Sergey Ryazanov
2024-10-29 10:47 ` [PATCH net-next v11 03/23] ovpn: add basic netlink support Antonio Quartulli
2024-11-08 23:15 ` Sergey Ryazanov
2024-11-15 10:05 ` Antonio Quartulli
2024-11-19 2:05 ` Sergey Ryazanov
2024-11-19 8:12 ` Antonio Quartulli
2024-11-08 23:31 ` Sergey Ryazanov
2024-11-15 10:19 ` Antonio Quartulli
2024-11-19 2:23 ` Sergey Ryazanov
2024-11-19 8:16 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 04/23] ovpn: add basic interface creation/destruction/management routines Antonio Quartulli
2024-11-09 1:01 ` Sergey Ryazanov
2024-11-12 16:47 ` Sabrina Dubroca
2024-11-12 23:56 ` Sergey Ryazanov
2024-11-14 8:07 ` Antonio Quartulli
2024-11-14 22:57 ` Sergey Ryazanov
2024-11-15 13:45 ` Antonio Quartulli
2024-11-15 13:00 ` Antonio Quartulli
2024-11-10 20:42 ` Sergey Ryazanov
2024-11-15 14:03 ` Antonio Quartulli
2024-11-19 3:08 ` Sergey Ryazanov
2024-11-19 8:45 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 05/23] ovpn: keep carrier always on Antonio Quartulli
2024-11-09 1:11 ` Sergey Ryazanov
2024-11-15 14:13 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 06/23] ovpn: introduce the ovpn_peer object Antonio Quartulli
2024-10-30 16:37 ` Sabrina Dubroca
2024-10-30 20:47 ` Antonio Quartulli
2024-11-05 13:12 ` Sabrina Dubroca
2024-11-12 10:12 ` Antonio Quartulli
2024-11-10 13:38 ` Sergey Ryazanov
2024-11-12 17:31 ` Sabrina Dubroca
2024-11-13 1:37 ` Sergey Ryazanov
2024-11-13 10:03 ` Sabrina Dubroca
2024-11-10 19:52 ` Sergey Ryazanov
2024-11-14 14:55 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 07/23] ovpn: introduce the ovpn_socket object Antonio Quartulli
2024-11-10 18:26 ` Sergey Ryazanov
2024-11-15 14:28 ` Antonio Quartulli
2024-11-19 13:44 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 08/23] ovpn: implement basic TX path (UDP) Antonio Quartulli
2024-10-30 17:14 ` Sabrina Dubroca
2024-10-30 20:58 ` Antonio Quartulli
2024-11-10 22:32 ` Sergey Ryazanov
2024-11-12 17:28 ` Sabrina Dubroca
2024-11-14 15:25 ` Antonio Quartulli
2024-11-10 23:54 ` Sergey Ryazanov
2024-11-15 14:39 ` Antonio Quartulli
2024-11-20 11:45 ` Sabrina Dubroca
2024-10-29 10:47 ` [PATCH net-next v11 09/23] ovpn: implement basic RX " Antonio Quartulli
2024-10-31 11:29 ` Sabrina Dubroca
2024-10-31 13:04 ` Antonio Quartulli
2024-11-11 1:54 ` Sergey Ryazanov
2024-11-15 15:02 ` Antonio Quartulli
2024-11-12 0:16 ` Sergey Ryazanov
2024-11-15 15:05 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 10/23] ovpn: implement packet processing Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 11/23] ovpn: store tunnel and transport statistics Antonio Quartulli
2024-10-31 11:37 ` Sabrina Dubroca
2024-10-31 13:12 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 12/23] ovpn: implement TCP transport Antonio Quartulli
2024-10-31 14:30 ` Antonio Quartulli
2024-10-31 15:25 ` Sabrina Dubroca
2024-11-16 0:33 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 13/23] ovpn: implement multi-peer support Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 14/23] ovpn: implement peer lookup logic Antonio Quartulli
2024-11-04 11:26 ` Sabrina Dubroca
2024-11-12 1:18 ` Sergey Ryazanov
2024-11-12 12:32 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 15/23] ovpn: implement keepalive mechanism Antonio Quartulli
2024-11-05 18:10 ` Sabrina Dubroca
2024-11-12 13:20 ` Antonio Quartulli [this message]
2024-11-13 10:36 ` Sabrina Dubroca
2024-11-14 8:12 ` Antonio Quartulli
2024-11-14 9:03 ` Sabrina Dubroca
2024-10-29 10:47 ` [PATCH net-next v11 16/23] ovpn: add support for updating local UDP endpoint Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 17/23] ovpn: add support for peer floating Antonio Quartulli
2024-11-04 11:24 ` Sabrina Dubroca
2024-11-12 13:52 ` Antonio Quartulli
2024-11-12 10:56 ` Sabrina Dubroca
2024-11-12 14:03 ` Antonio Quartulli
2024-11-13 11:25 ` Sabrina Dubroca
2024-11-14 8:26 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 18/23] ovpn: implement peer add/get/dump/delete via netlink Antonio Quartulli
2024-11-04 15:14 ` Sabrina Dubroca
2024-11-12 14:19 ` Antonio Quartulli
2024-11-13 16:56 ` Sabrina Dubroca
2024-11-14 9:21 ` Antonio Quartulli
2024-11-20 11:12 ` Sabrina Dubroca
2024-11-20 11:34 ` Antonio Quartulli
2024-11-11 15:41 ` Sabrina Dubroca
2024-11-12 14:26 ` Antonio Quartulli
2024-11-13 11:05 ` Sabrina Dubroca
2024-11-14 10:32 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 19/23] ovpn: implement key add/get/del/swap " Antonio Quartulli
2024-11-05 10:16 ` Sabrina Dubroca
2024-11-12 15:40 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 20/23] ovpn: kill key and notify userspace in case of IV exhaustion Antonio Quartulli
2024-11-05 10:33 ` Sabrina Dubroca
2024-11-12 15:44 ` Antonio Quartulli
2024-11-13 14:28 ` Sabrina Dubroca
2024-11-14 10:38 ` Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 21/23] ovpn: notify userspace when a peer is deleted Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 22/23] ovpn: add basic ethtool support Antonio Quartulli
2024-10-29 10:47 ` [PATCH net-next v11 23/23] testing/selftests: add test tool and scripts for ovpn module Antonio Quartulli
2024-10-31 10:00 ` [PATCH net-next v11 00/23] Introducing OpenVPN Data Channel Offload Antonio Quartulli
2024-11-01 2:12 ` Jakub Kicinski
2024-11-01 2:20 ` patchwork-bot+netdevbpf
2024-11-06 1:18 ` Sergey Ryazanov
2024-11-14 15:33 ` Antonio Quartulli
2024-11-14 22:10 ` Sergey Ryazanov
2024-11-15 15:08 ` 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=189dbeea-127a-47e8-84f8-c8cf1cc03536@openvpn.net \
--to=antonio@openvpn.net \
--cc=andrew@lunn.ch \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--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=sd@queasysnail.net \
--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