On 26/03/2024 11:34, Esben Haabendal wrote:

Antonio Quartulli [off-list ref] writes:

quoted

+static inline bool ovpn_bind_skb_src_match(const struct ovpn_bind *bind, struct sk_buff *skb)
+{
+	const unsigned short family = skb_protocol_to_family(skb);
+	const struct ovpn_sockaddr *sa = &bind->sa;

You should move this dereferencing of bind to after the following check
to avoid segmentation fault.

ouch. good catch, thanks!

quoted

+	if (unlikely(!bind))
+		return false;

quoted

diff --git a/drivers/net/ovpn/peer.c b/drivers/net/ovpn/peer.c
new file mode 100644
index 000000000000..4319271927a4
--- /dev/null
+++ b/drivers/net/ovpn/peer.c
+
+/* Use with kref_put calls, when releasing refcount
+ * on ovpn_peer objects.  This method should only
+ * be called from process context with config_mutex held.
+ */
+void ovpn_peer_release_kref(struct kref *kref)
+{
+	struct ovpn_peer *peer = container_of(kref, struct ovpn_peer, refcount);
+
+	INIT_WORK(&peer->delete_work, ovpn_peer_delete_work);

Is this safe, or could we end up re-initializing delete_work while it is
queued or running?

ovpn_peer_release_kref() is only invoked once upon peer refcounter 
reaching 0 (then the peer object is erased).
Therefore it should be safe to init the work object here.

Cheers,

quoted

+	queue_work(peer->ovpn->events_wq, &peer->delete_work);

/Esben

-- 
Antonio Quartulli
OpenVPN Inc.