Re: [PATCH net-next 10/10] ovpn: ensure sk is still valid during cleanup
From: Antonio Quartulli <antonio@openvpn.net>
Date: 2025-05-13 14:55:47
On 13/05/2025 11:19, Antonio Quartulli wrote: [...]
quoted
Side note: the ovpn_socket refcount release/detach path looks wrong, at least in case of an UDP socket, as ovpn_udp_socket_detach() calls setup_udp_tunnel_sock() which in turns will try to _increment_ various core counters, instead of decreasing them (i.e. udp_encap_enable should be wrongly accounted after that call).You're right. I had the impression I needed to "undo" the setup. I see now that the encap key is decremented in the UDP sock destroy, right after having called my implementation of .destroy(). I'll drop the call to setup_udp_tunnel_sock() with empty config then.
Paolo, the reason for calling setup_udp_tunnel_sock() with an empty
config was to "reset" its encap state (for udp_tunnel).
Technically a UDP socket could go back to being a pure userspace socket
only (i.e. when all peers using that socket have been deleted),
therefore I wanted to make sure that the kernel would not try to
intercept its packets anymore.
I understand setup_udp_tunnel_sock(cfg={}) is not correct, but what are
my options?
1) I could nullify manually sk_user_data and udp_sk(sk)->encap_type;
2) I could implement something like "stop_udp_tunnel_sock()" that
reverts what setup_udp_tunnel_sock() had done and call it.
Opinions?
I'd go with 2.
Thanks a lot!
--
Antonio Quartulli
OpenVPN Inc.