linux-kernel - Re: [PATCH net-next v2] net: vrf: don't down the interface when add slave

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: <aJhNP_xQyENLSF6d@shredder>
Date: Sun, 10 Aug 2025 10:41:51 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Menglong Dong <menglong8.dong@...il.com>
Cc: dsahern@...nel.org, andrew+netdev@...n.ch, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	horms@...nel.org, sdf@...ichev.me, kuniyu@...gle.com,
	ahmed.zaki@...el.com, aleksander.lobakin@...el.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2] net: vrf: don't down the interface when add
 slave

On Thu, Aug 07, 2025 at 01:56:34PM +0800, Menglong Dong wrote:
> For now, cycle_netdev() will be called to flush the neighbor cache when
> add slave by downing and upping the slave netdev. When the slave has
> vlan devices, the data transmission can interrupted.

OK, but can you provide more details on the production use case for
enslaving the real device to a VRF during runtime? Usually this kind of
configuration is performed before data transmission begins. I suspect
this is why nobody complained about this behavior despite being present
in the VRF driver since its initial submission almost a decade ago.

I'm asking because the potential for regressions from this patch seems
quite high to me. For example, before this patch nexthop objects using
the enslaved device would get flushed, but now they persist. This can
impact offload of nexthop objects and it's possible I'm missing more
potential regressions.

Before:

# ip link add name dummy1 up type dummy
# ip link add name vrf1 up type vrf table 100
# ip address add 192.0.2.1/24 dev dummy1
# ip nexthop add id 1 via 192.0.2.2 dev dummy1
# ip nexthop
id 1 via 192.0.2.2 dev dummy1 scope link
# ip link set dev dummy1 master vrf1
# ip nexthop
# echo $?
0

After:

# ip link add name dummy1 up type dummy
# ip link add name vrf1 up type vrf table 100
# ip address add 192.0.2.1/24 dev dummy1
# ip nexthop add id 1 via 192.0.2.2 dev dummy1
# ip nexthop
id 1 via 192.0.2.2 dev dummy1 scope link 
# ip link set dev dummy1 master vrf1
# ip nexthop
id 1 via 192.0.2.2 dev dummy1 scope link 

> 
> Optimize it by introducing the NETDEV_VRF_MASTER event. When a net device
> is added to the slave of the vrf, the NETDEV_VRF_MASTER event will be
> triggered, and the neighbor cache will be flushed, and the routes will be
> moved to the corresponding table.
> 
> The moving of the routes across tables is tested with following command:
> 
>   $ ip link add name dummy1 up type dummy
>   $ sysctl -wq net.ipv6.conf.dummy1.keep_addr_on_down=1
>   $ ip address add 192.0.2.1/24 dev dummy1
>   $ ip address add 2001:db8:1::1/64 dev dummy1
>   $ ip link add name vrf1 up type vrf table 100
>   $ ip link set dev dummy1 master vrf1
> 
>   $ ip -6 r show table 100
>   local 2001:db8:1::1 dev dummy1 proto kernel metric 0 pref medium
>   2001:db8:1::/64 dev dummy1 proto kernel metric 256 pref medium
>   local fe80::cc26:8ff:fe02:ae95 dev dummy1 proto kernel metric 0 pref medium
>   fe80::/64 dev dummy1 proto kernel metric 256 pref medium
>   multicast ff00::/8 dev dummy1 proto kernel metric 256 pref medium
> 
>   $ ip -4 r show table 100
>   192.0.2.0/24 dev dummy1 proto kernel scope link src 192.0.2.1
>   local 192.0.2.1 dev dummy1 proto kernel scope host src 192.0.2.1
>   broadcast 192.0.2.255 dev dummy1 proto kernel scope link src 192.0.2.1
> 
> Signed-off-by: Menglong Dong <dongml2@...natelecom.cn>