netdev - 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: <8358d907-0edc-4ff0-a520-9cec3c84a49a@kernel.org>
Date: Sun, 10 Aug 2025 18:03:12 -0600
From: David Ahern <dsahern@...nel.org>
To: Ido Schimmel <idosch@...sch.org>, Menglong Dong <menglong8.dong@...il.com>
Cc: 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 8/10/25 1:41 AM, Ido Schimmel wrote:
> 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.
> 

+1

Thanks for staying on top of this, Ido. I have been very distracted the
past few months.

The design choices when the VRF code was first written was either
1) require the devices to be added to a VRF while down, or
2) cycle the device while adding it to the VRF.

I preferred 2 as the simplest choice for users, and so that is the way
the feature went in.