netdev - Re: [PATCH net-next v19 00/26] Introducing OpenVPN Data Channel Offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2dc054c7-c596-b283-b26a-86c52e48efe0@gmail.com>
Date: Thu, 13 Feb 2025 09:26:14 -0500
From: Sean Anderson <seanga2@...il.com>
To: Antonio Quartulli <antonio@...nvpn.net>, 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>, sd@...asysnail.net, ryazanov.s.a@...il.com,
 Andrew Lunn <andrew+netdev@...n.ch>
Cc: 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

Hi Antonio,

On 2/10/25 19:39, Antonio Quartulli wrote:
> NOTE: TCP tests are still showing the following warning while running
> iperf.
> I have analysed the report several times, but it definitely looks like
> a false positive to me, so nothing to worry about.
> 
> Basically the lockdep engine gets confused thinking that we are
> acquiring the lock twice on the same sock, but actually:
> 1) the kernel is first locking the 'iperf' (user) TCP socket;
> 2) ovpn is later locking the underlying TCP trasport socket.
> 
> 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 think you can use a "nested" lock to avoid this. See e.g. commit
86a41ea9fd79 ("l2tp: fix lockdep splat") for an example.

--Sean

[1] https://www.kernel.org/doc/html/latest/locking/lockdep-design.html#exception-nested-data-dependencies-leading-to-nested-locking