[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <090524ac-724d-4915-8699-fe2ae736ab8c@openvpn.net>
Date: Thu, 13 Feb 2025 12:46:34 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Donald Hunter <donald.hunter@...il.com>, Shuah Khan <shuah@...nel.org>,
ryazanov.s.a@...il.com, Andrew Lunn <andrew+netdev@...n.ch>,
Simon Horman <horms@...nel.org>, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, Xiao Liang <shaw.leon@...il.com>,
steffen.klassert@...unet.com, antony.antony@...unet.com,
willemdebruijn.kernel@...il.com, David Ahern <dsahern@...nel.org>,
Andrew Lunn <andrew@...n.ch>, Shuah Khan <skhan@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH net-next v19 00/26] Introducing OpenVPN Data Channel
Offload
On 13/02/2025 00:34, Sabrina Dubroca wrote:
> Hello,
>
> 2025-02-11, 01:39:53 +0100, Antonio Quartulli wrote:
>> All minor and major reported problems have been finally addressed.
>> Big thanks to Sabrina, who took the time to guide me through
>> converting the peer socket to an RCU pointer.
>
> Something is off (not sure if it's new to this version): if I use
> test-tcp.sh to setup a set of interfaces and peers (I stop the test
> just after setup to keep the environment alive), then remove all netns
> with "ip -all netns delete", I expect all devices to go away, but they
> don't. With debug messages enabled I'm seeing some activity from the
> module ("tun0: sending keepalive to peer 3" and so on), and
> ovpn_net_uninit/ovpn_priv_free never got called.
I can reproduce it. If later I rmmod ovpn I then get all the "Deleting
peer" messages.
So instances are not being purged on netns exit.
Will dive into it.
>
> [...]
>> So there is NO risk of deadlock (and indeed nothing hangs), but I
>> couldn't find a way to make the warning go away.
>
> I've spotted another splat on strparser cleanup that looked like an
> actual deadlock, but it's not very reproducible. Still looking into
> it, but I'm not convinced it's ok to call strp_done (as is done from
> ovpn_tcp_socket_detach) while under lock_sock, because AFAIU
> cancel_work_sync(&strp->work) may be waiting for a work that needs to
> lock the socket (cb.lock in do_strp_work). I guess tcp_tx_work would
> have the same problem.
Will have a look here too.
Thanks!
--
Antonio Quartulli
OpenVPN Inc.
Powered by blists - more mailing lists