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

Message-ID: <CADxym3Y_XmmmCM3Mc46P8vmXE2vZ1+co6g7Z1VEpuT8WHt6+UA@mail.gmail.com>
Date: Mon, 11 Aug 2025 09:14:33 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: David Ahern <dsahern@...nel.org>
Cc: Ido Schimmel <idosch@...sch.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 Mon, Aug 11, 2025 at 8:03 AM David Ahern <dsahern@...nel.org> wrote:
>
> 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.

I see.  The use case is that we want to use VRF for a living
environment and without breaking the traffic on the VLAN. It
seems that it's not a normal use case and we are using it in the
wrong way.

Thanks for Ido's and David's reply ;)

Menglong Dong