netdev - Re: [PATCH net-next v2 5/8] net: ip_gre: Add netns

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: <CABAhCOTFyXVw=ucjMfHbgmLF_xe+Y=By_RixEnxFh+s4raS-sA@mail.gmail.com>
Date: Tue, 12 Nov 2024 14:05:19 +0800
From: Xiao Liang <shaw.leon@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, Kuniyuki Iwashima <kuniyu@...zon.com>, 
	"David S. Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Ido Schimmel <idosch@...dia.com>, 
	Andrew Lunn <andrew+netdev@...n.ch>, Simon Horman <horms@...nel.org>, 
	Donald Hunter <donald.hunter@...il.com>, Shuah Khan <shuah@...nel.org>, 
	Jiri Pirko <jiri@...nulli.us>, Hangbin Liu <liuhangbin@...il.com>
Subject: Re: [PATCH net-next v2 5/8] net: ip_gre: Add netns_atomic module parameter

On Tue, Nov 12, 2024 at 7:42 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Mon, 11 Nov 2024 16:15:41 +0800 Xiao Liang wrote:
> > > Let's start with annotating the drivers which need the old behavior.
> > > It seems like something that was done as a workaround for old drivers,
> > > maybe there isn't that many of them and we can convert them all in one
> > > series.
> >
> > I'd like to clarify a bit here.
> > Link netns is closely coupled with source netns, as it's passed to drivers
> > as source netns. Without introducing a flag, after applying the logic in
> > this patchset, drivers won't be able to distinguish the two:
> >   1) ip -n ns1 link add netns ns2 ...
> >   2) ip link add netns ns2 link-netns ns1 ...
>
> True, but the question is how many drivers actually care about the net
> parameter. Ideally we would pass both netns to the drivers, refactor
> the ->newlink callback to take a parameter struct and add both netns
> as members. Passing just one or the other will always be confusing.
>

Got it, thanks. Will work on a v3.

> > There's no problem for drivers that already handle source netns.
> > But it changes the semantics of 1) for ip tunnels silently. The effective
> > link-netns is ns2 before, and will be changed to ns1 afterwards, which will
> > almost certainly affect some users. Is this acceptable?
>
> No, changing the behavior for the commands you provided is not
> acceptable. At the same time we shouldn't be adding technical debt
> of supporting both converted and unconverted drivers upstream.
>
> > On the other hand, do we need to deal with out-of-tree drivers?
>
> Nope, but again, changing the prototype of newlink would also make it
> hard to get wrong for OOT modules.