[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM_iQpWj2MoQNFvRxjxz5wL15NYckoefK3SssiTu9YF-VffpSg@mail.gmail.com>
Date: Tue, 14 Nov 2017 10:53:51 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Jamal Hadi Salim <jhs@...atatu.com>, mlxsw@...lanox.com,
Ido Schimmel <idosch@...lanox.com>,
Eric Dumazet <edumazet@...gle.com>,
Willem de Bruijn <willemb@...gle.com>,
tcharding <me@...in.cc>,
John Fastabend <john.fastabend@...il.com>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [patch net] net: forbid netdev used by mirred tc act from being
moved to another netns
On Mon, Nov 13, 2017 at 10:35 PM, Jiri Pirko <jiri@...nulli.us> wrote:
>
> Okay. What about my question? Should we allow adding an action mirred
> pointing to a netdev in another netns? I think it would make sense in
> case we consider movement of mirred device legit.
I don't think it is possible to add an action pointing to any netdev in
other netns in current code base, you just can't find it.
Moving a netdev after linking it to an action is different, if you want to
argue this using above question. Because we allow other "linking"
netdev to be moved too, like a tunnel device on top of a physical
one (this is why we have netnsid).
The "linking" of a mirred action might not be as strong as a tunnel
device "linking", but the idea is pretty much similar, I don't see
anything fundamentally wrong.
Powered by blists - more mailing lists