* [PATCH net-next] net: vrf: Do not allow looback to be moved to a VRF
@ 2017-04-26 14:58 David Ahern
2017-04-27 2:44 ` Greg Rose
2017-04-27 20:50 ` David Miller
0 siblings, 2 replies; 3+ messages in thread
From: David Ahern @ 2017-04-26 14:58 UTC (permalink / raw)
To: netdev; +Cc: rshearma, David Ahern
Moving the loopback into a VRF breaks networking for the default VRF.
Since the VRF device is the loopback for VRF domains, there is no
reason to move the loopback. Given the repercussions, block attempts
to set lo into a VRF.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
drivers/net/vrf.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index aa5d30428bba..ceda5861da78 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -877,6 +877,12 @@ static int do_vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
{
int ret;
+ /* do not allow loopback device to be enslaved to a VRF.
+ * The vrf device acts as the loopback for the vrf.
+ */
+ if (port_dev == dev_net(dev)->loopback_dev)
+ return -EOPNOTSUPP;
+
port_dev->priv_flags |= IFF_L3MDEV_SLAVE;
ret = netdev_master_upper_dev_link(port_dev, dev, NULL, NULL);
if (ret < 0)
--
2.1.4
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH net-next] net: vrf: Do not allow looback to be moved to a VRF
2017-04-26 14:58 [PATCH net-next] net: vrf: Do not allow looback to be moved to a VRF David Ahern
@ 2017-04-27 2:44 ` Greg Rose
2017-04-27 20:50 ` David Miller
1 sibling, 0 replies; 3+ messages in thread
From: Greg Rose @ 2017-04-27 2:44 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, rshearma
On Wed, 2017-04-26 at 07:58 -0700, David Ahern wrote:
> Moving the loopback into a VRF breaks networking for the default VRF.
> Since the VRF device is the loopback for VRF domains, there is no
> reason to move the loopback. Given the repercussions, block attempts
> to set lo into a VRF.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> ---
> drivers/net/vrf.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
> index aa5d30428bba..ceda5861da78 100644
> --- a/drivers/net/vrf.c
> +++ b/drivers/net/vrf.c
> @@ -877,6 +877,12 @@ static int do_vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
> {
> int ret;
>
> + /* do not allow loopback device to be enslaved to a VRF.
> + * The vrf device acts as the loopback for the vrf.
> + */
> + if (port_dev == dev_net(dev)->loopback_dev)
> + return -EOPNOTSUPP;
> +
> port_dev->priv_flags |= IFF_L3MDEV_SLAVE;
> ret = netdev_master_upper_dev_link(port_dev, dev, NULL, NULL);
> if (ret < 0)
I think that's a great idea.
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH net-next] net: vrf: Do not allow looback to be moved to a VRF
2017-04-26 14:58 [PATCH net-next] net: vrf: Do not allow looback to be moved to a VRF David Ahern
2017-04-27 2:44 ` Greg Rose
@ 2017-04-27 20:50 ` David Miller
1 sibling, 0 replies; 3+ messages in thread
From: David Miller @ 2017-04-27 20:50 UTC (permalink / raw)
To: dsa; +Cc: netdev, rshearma
From: David Ahern <dsa@cumulusnetworks.com>
Date: Wed, 26 Apr 2017 07:58:22 -0700
> Moving the loopback into a VRF breaks networking for the default VRF.
> Since the VRF device is the loopback for VRF domains, there is no
> reason to move the loopback. Given the repercussions, block attempts
> to set lo into a VRF.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied, thanks David.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-04-27 20:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-04-26 14:58 [PATCH net-next] net: vrf: Do not allow looback to be moved to a VRF David Ahern
2017-04-27 2:44 ` Greg Rose
2017-04-27 20:50 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).