netdev - Re: [PATCH net] ipvlan: Make the addrs

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: <4a0b0695-f13e-4611-a6a5-524b4967ff6e@huawei.com>
Date: Mon, 15 Dec 2025 20:00:52 +0300
From: Dmitry Skorodumov <skorodumov.dmitry@...wei.com>
To: <netdev@...r.kernel.org>, Xiao Liang <shaw.leon@...il.com>, Jakub Kicinski
	<kuba@...nel.org>, Kuniyuki Iwashima <kuniyu@...gle.com>, Guillaume Nault
	<gnault@...hat.com>, Julian Vetter <julian@...er-limits.org>, Eric Dumazet
	<edumazet@...gle.com>, Stanislav Fomichev <sdf@...ichev.me>, Etienne
 Champetier <champetier.etienne@...il.com>, "David S. Miller"
	<davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
	<linux-kernel@...r.kernel.org>
CC: Andrew Lunn <andrew+netdev@...n.ch>
Subject: Re: [PATCH net] ipvlan: Make the addrs_lock be per port

I'm working currently on some selftests/net for ipvtap for some kind of test (test calls "ip a a/ip a d" in several threads), but I'm unsure how to proceed:

This patch is supposed to be a "fix". But selftest - obviously not a fix.

So, I'm unsure how to send a selftest for this.

Dmitry


On 15.12.2025 19:54, Dmitry Skorodumov wrote:
> Make the addrs_lock be per port, not per ipvlan dev.
>
> Initial code seems to be written in the assumption,
> that any address change must occur under RTNL.
> But it is not so for the case of IPv6. So
>
> 1) Introduce per-port addrs_lock.
>
> 2) It was needed to fix places where it was forgotten
> to take lock (ipvlan_open/ipvlan_close)
>
> 3) Fix places, where list_for_each_entry_rcu()
> was used to iterate the list while holding a lock
>
> This appears to be a very minor problem though.
> Since it's highly unlikely that ipvlan_add_addr() will
> be called on 2 CPU simultaneously. But nevertheless,
> this could cause:
>
> 1) False-negative of ipvlan_addr_busy(): one interface
> iterated through all port->ipvlans + ipvlan->addrs
> under some ipvlan spinlock, and another added IP
> under its own lock. Though this is only possible
> for IPv6, since looks like only ipvlan_addr6_event() can be
> called without rtnl_lock.
>
> 2) Race since ipvlan_ht_addr_add(port) is called under
> different ipvlan->addrs_lock locks
>
> This should not affect performance, since add/remove IP
> is a rare situation and spinlock is not taken on fast
> paths.
>
> Fixes: 8230819494b3 ("ipvlan: use per device spinlock to protect addrs list updates")
> Signed-off-by: Dmitry Skorodumov <skorodumov.dmitry@...wei.com>
> CC: Paolo Abeni <pabeni@...hat.com>
> Signed-off-by: Dmitry Skorodumov <skorodumov.dmitry@...wei.com>