netdev - Re: [RFC PATCH] ipv6: route: release reference of dsts cached in sockets

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] [day] [month] [year] [list]

Message-ID: <20241009133929.GA3765@incl>
Date: Wed, 9 Oct 2024 15:39:29 +0200
From: Jiri Wiesner <jwiesner@...e.de>
To: Xin Long <lucien.xin@...il.com>
Cc: Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
	David Ahern <dsahern@...nel.org>, Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC PATCH] ipv6: route: release reference of dsts cached in
 sockets

On Sun, Oct 06, 2024 at 02:25:25PM -0400, Xin Long wrote:
> We recently also encountered this
> 
>   'unregister_netdevice: waiting for lo to become free. Usage count = X'
> 
> problem on our customer env after backporting
> 
>   Commit 92f1655aa2b22 ("net: fix __dst_negative_advice() race"). [1]
> 
> The commit looks correct to me, so I guess it may uncover some existing
> issues.

That is interesting. It seems possible to me.

> As it took a very long time to get reproduced on our customer env, which
> made it impossible to debug. Also the issue existed even after
> disabling IPv6.

AFAIK, the reproducibility of the issue hinges on net namespaces being created and destroyed often and TCP connections timing out in the namespaces. Traffic rate does not seem important.

> It seems much easier to reproduce it on your customer env. So I'm wondering

It takes roughly 24 hours but sometimes much more or much less to reproduce this.

> - Was the testing on your customer env related to IPv6 ?

Yes, it was. But I don't think the customer can disable IPv6. Their product is based on IPv6.

> - Does the issue still exist after reverting the commit [1] ?

I will ask the customer for a test.

Also, the issue is not reproducible after e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev") was backported.
J.