| Message ID | 1462959859-6669-3-git-send-email-aar@pengutronix.de (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
Hello. On 11/05/16 11:44, Alexander Aring wrote: > This patch reverts commit f9d1ce8f81eb ("ieee802154: fix netns settings"). > The lowpan interface need to be created inside the net namespace where > the wpan interface is available. The wpan namespace can be changed only > by nl802154 before. Without this patch it's not possible to create a > lowpan interface for a wpan interface which isn't inside init_net > namespace. > > Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> > Signed-off-by: Alexander Aring <aar@pengutronix.de> > --- > net/ieee802154/6lowpan/core.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c > index dd085db..096e3db 100644 > --- a/net/ieee802154/6lowpan/core.c > +++ b/net/ieee802154/6lowpan/core.c > @@ -131,8 +131,7 @@ static int lowpan_newlink(struct net *src_net, struct net_device *ldev, > > pr_debug("adding new link\n"); > > - if (!tb[IFLA_LINK] || > - !net_eq(dev_net(ldev), &init_net)) > + if (!tb[IFLA_LINK]) > return -EINVAL; > /* find and hold wpan device */ > wdev = dev_get_by_index(dev_net(ldev), nla_get_u32(tb[IFLA_LINK])); Reviewed-by: Stefan Schmidt<stefan@osg.samsung.com> regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Alexander Aring <aar@pengutronix.de> wrote: > This patch reverts commit f9d1ce8f81eb ("ieee802154: fix netns settings"). > The lowpan interface need to be created inside the net namespace where > the wpan interface is available. The wpan namespace can be changed only > by nl802154 before. Without this patch it's not possible to create a > lowpan interface for a wpan interface which isn't inside init_net > namespace. I know that we can't support multiple lowpan interfaces on a single wpan at this time. If one could, via a macvlan like way, would we want to put different lowpan interfaces in different netns on top of the same physical radio. I'm also ignorant here: can one create macvlan against a physical interface into a netns? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 05/11/2016 07:14 PM, Michael Richardson wrote: > Alexander Aring <aar@pengutronix.de> wrote: > > This patch reverts commit f9d1ce8f81eb ("ieee802154: fix netns settings"). > > The lowpan interface need to be created inside the net namespace where > > the wpan interface is available. The wpan namespace can be changed only > > by nl802154 before. Without this patch it's not possible to create a > > lowpan interface for a wpan interface which isn't inside init_net > > namespace. > > I know that we can't support multiple lowpan interfaces on a single wpan > at this time. If one could, via a macvlan like way, would we want to > put different lowpan interfaces in different netns on top of the same > physical radio. > mhh, this patch currently sets the whole phy into a namespace and all related interfaces wpan/lowpan can only exists according the namespace which the phy belongs to. Running wpan interface in netns A and running the corresponding lowpan interface in an another namespace sounds wrong for me, because they should known each other. btw: I tried to use "ip link set $WPAN/$LOWPAN netns $NETNS" doesn't work, it returns -EINVAL. I think this works only if we set some flags/callbacks, don't know but was one of my test cases. If running iwpan $PHY set netns name $NETNS, the wpan interface will unregister(deleting lowpan) and will be registered again (inside different namespace). --- (Creating multiple lowpans for one wpan) This can be done when creating two wpan interfaces according one phy. The bad news is, you can't change the mac address stuff and I think this isn't what you want. The reason is simple, most hardwares has one address filtering setting only. You could have two wpan interfaces with different address settings, but then one interface can be in up state only. To avoid such behaviour, I had in my mind to simple go into promiscuous mode if two wpan interfaces are up with different address settings, then let do linux do all filtering stuff. I had to avoid that because the hardware will not filtering anything anymore and linux need to do more "work". Maybe just go into promiscuous when it's necessary and print some WARNING that the device going into promiscuous mode in such setup. > I'm also ignorant here: can one create macvlan against a physical interface > into a netns? > What I googled is, yes that's possible. But they use "ip link set $INTERFACE netns $NETNS" for that, I think we need to implement such feature for wpan/lowpan stuff. But I don't know how it works when the $PHY isn't visible inside the namespace where the interface should be changed to. But wireless should have the same behaviour then, that the macvlan/veth/etc. the corresponding wireless phy isn't visible in the namespace. Seems there exists some "parent" device inside one namespace and macvlan/veth can be moved to other namespaces, but I am not an expert into that. :-) - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 12/05/2016 01:34, Alexander Aring a écrit : [snip] > But I don't know how it works when the $PHY isn't visible inside the > namespace where the interface should be changed to. But wireless should > have the same behaviour then, that the macvlan/veth/etc. the corresponding > wireless phy isn't visible in the namespace. Seems there exists some > "parent" device inside one namespace and macvlan/veth can be moved to > other namespaces, but I am not an expert into that. :-) Yes, the virtual interface (macvlan/veth,ip tunnels, vxlan, etc.) is created in the namespace of the physical netns. After, the virtual interface is moved to another netns (with 'ip link set foo netns bar'). This is called x-netns: the upper par of the interface and the link part are not in the same netns. With 'ip -d link' it's possible to show the link netns. There is an nsid which identified the link netns. The nsid is valid only in the current netns (ie the same netns can have another nsid in another netns). Usually, there are explicit boundary in the code when crossing netns (see skb_scrub_packet for example). Example with a gre interface: # create a gre interface in netns1 ip netns exec netns1 ip link add dev tun1 type gre local 10.0.0.1 \ remote 10.0.0.2 # move it in netns2: the link netns is still in netns1 ip netns exec netns1 ip link set tun1 netns netns2 or (completely equivalent): # assign a nsid to netns1 in netns2 ip exec netns2 ip netns set netns1 1234 # create a gre interface in netns2 with its link netns in netns1 ip exec netns2 ip link add tun1 link-netnsid 1234 type gre local 10.0.0.1 \ remote 10.0.0.2 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 05/12/2016 09:28 AM, Nicolas Dichtel wrote: > Le 12/05/2016 01:34, Alexander Aring a écrit : > [snip] >> But I don't know how it works when the $PHY isn't visible inside the >> namespace where the interface should be changed to. But wireless should >> have the same behaviour then, that the macvlan/veth/etc. the corresponding >> wireless phy isn't visible in the namespace. Seems there exists some >> "parent" device inside one namespace and macvlan/veth can be moved to >> other namespaces, but I am not an expert into that. :-) > Yes, the virtual interface (macvlan/veth,ip tunnels, vxlan, etc.) is created in > the namespace of the physical netns. After, the virtual interface is moved to > another netns (with 'ip link set foo netns bar'). This is called x-netns: the > upper par of the interface and the link part are not in the same netns. > With 'ip -d link' it's possible to show the link netns. There is an nsid which > identified the link netns. The nsid is valid only in the current netns (ie the > same netns can have another nsid in another netns). > Usually, there are explicit boundary in the code when crossing netns (see > skb_scrub_packet for example). > > Example with a gre interface: > > # create a gre interface in netns1 > ip netns exec netns1 ip link add dev tun1 type gre local 10.0.0.1 \ > remote 10.0.0.2 > # move it in netns2: the link netns is still in netns1 > ip netns exec netns1 ip link set tun1 netns netns2 > > or (completely equivalent): > > # assign a nsid to netns1 in netns2 > ip exec netns2 ip netns set netns1 1234 > # create a gre interface in netns2 with its link netns in netns1 > ip exec netns2 ip link add tun1 link-netnsid 1234 type gre local 10.0.0.1 \ > remote 10.0.0.2 Thanks for the explanation. The current patch series put the whole phy and all the interfaces into one net namespace (like in wireless). The lowpan interface can also be created in non init_net then. So far I know it's not possible to move wpan or lowpan interfaces after creation e.g. running "ip link set #IF netns $NETNS_NAME" and we need to support such behaviour in future. The current use-case is just for the fakelb driver (like hwsim in wireless) which doesn't do any optimization in IPv6 stack if two interfaces belongs to the same net namespace. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 05/13/2016 02:27 PM, Alexander Aring wrote: > > Hi, > > On 05/12/2016 09:28 AM, Nicolas Dichtel wrote: >> Le 12/05/2016 01:34, Alexander Aring a écrit : >> [snip] >>> But I don't know how it works when the $PHY isn't visible inside the >>> namespace where the interface should be changed to. But wireless should >>> have the same behaviour then, that the macvlan/veth/etc. the corresponding >>> wireless phy isn't visible in the namespace. Seems there exists some >>> "parent" device inside one namespace and macvlan/veth can be moved to >>> other namespaces, but I am not an expert into that. :-) >> Yes, the virtual interface (macvlan/veth,ip tunnels, vxlan, etc.) is created in >> the namespace of the physical netns. After, the virtual interface is moved to >> another netns (with 'ip link set foo netns bar'). This is called x-netns: the >> upper par of the interface and the link part are not in the same netns. >> With 'ip -d link' it's possible to show the link netns. There is an nsid which >> identified the link netns. The nsid is valid only in the current netns (ie the >> same netns can have another nsid in another netns). >> Usually, there are explicit boundary in the code when crossing netns (see >> skb_scrub_packet for example). >> >> Example with a gre interface: >> >> # create a gre interface in netns1 >> ip netns exec netns1 ip link add dev tun1 type gre local 10.0.0.1 \ >> remote 10.0.0.2 >> # move it in netns2: the link netns is still in netns1 >> ip netns exec netns1 ip link set tun1 netns netns2 >> >> or (completely equivalent): >> >> # assign a nsid to netns1 in netns2 >> ip exec netns2 ip netns set netns1 1234 >> # create a gre interface in netns2 with its link netns in netns1 >> ip exec netns2 ip link add tun1 link-netnsid 1234 type gre local 10.0.0.1 \ >> remote 10.0.0.2 > > Thanks for the explanation. > > The current patch series put the whole phy and all the interfaces into > one net namespace (like in wireless). The lowpan interface can also be > created in non init_net then. > I detected today that on non init_net lowpan interfaces will not work with our current "pending for real UAPI" solution which is "debugfs". So this is broken right now, but I don't really care about that for setting which will be part of some UAPI netlink/sysfs/etc. later, which will be netns aware. The files in debugfs entries will be not be available, maybe there exists also solutions to do this namespace aware. If somebody wants to test stateful compression with e.g. fakelb, etc. init_net is the one namespace which will work only. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c index dd085db..096e3db 100644 --- a/net/ieee802154/6lowpan/core.c +++ b/net/ieee802154/6lowpan/core.c @@ -131,8 +131,7 @@ static int lowpan_newlink(struct net *src_net, struct net_device *ldev, pr_debug("adding new link\n"); - if (!tb[IFLA_LINK] || - !net_eq(dev_net(ldev), &init_net)) + if (!tb[IFLA_LINK]) return -EINVAL; /* find and hold wpan device */ wdev = dev_get_by_index(dev_net(ldev), nla_get_u32(tb[IFLA_LINK]));
This patch reverts commit f9d1ce8f81eb ("ieee802154: fix netns settings"). The lowpan interface need to be created inside the net namespace where the wpan interface is available. The wpan namespace can be changed only by nl802154 before. Without this patch it's not possible to create a lowpan interface for a wpan interface which isn't inside init_net namespace. Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Alexander Aring <aar@pengutronix.de> --- net/ieee802154/6lowpan/core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)