On 2015-02-02 16:58, Nicolas Dichtel wrote: > Le 30/01/2015 21:00, Arvid Brodin a écrit : >> On 2015-01-26 22:28, Nicolas Dichtel wrote: >> *snip* >>> - HSR subsystem uses src_net to parse IFLA_HSR_SLAVE[1|2], but the netdevice has >>> the flag NETIF_F_NETNS_LOCAL, so the question is: does this netdevice really >>> supports x-netns? If not, the newlink handler should use the dest_net instead >>> of src_net, I can provide the patch. >> *snip* >> >> As the author of the HSR driver, I'd like to answer this question, but unfortunately >> I don't know what x-netns is. Neither Google nor Documentation/ has been particularly >> helpful. >> >> Care to elaborate? (Maybe this is a moot point now that the patch has been accepted, >> but I'd still like to understand, if you have the time to explain.) > Basically, network namespaces (netns) allow you to run several independant > instances of the linux networking stack. > Network interfaces are bound to one netns. By default, only one netns exists > (named init_net) when you boot your kernel. > For logical interfaces, they are usually bound to a link layer. For example, if > I understand well, hsr network interfaces receive and send their packets from > two physical interfaces (IFLA_HSR_SLAVE[1|2]). > Now imagine that these slaves are in a netns foo and the logical hsr interfaces > in netns bar. You have a x-netns interface, the link layer part of the interface > is not in the same netns than the upper part. A user will see the hsr interface > in netns bar, but this interface will send a receive packet in netns foo. Ok, so x-netns simply means cross-netns? > Usually, to configure an interface like this, you create it in netns foo and you > move it later to netns bar (ip link set hsr1 netns bar). The flag > NETIF_F_NETNS_LOCAL forbids this operation, you cannot move it to another netns. > But you still can create a x-netns interface: > ip netns add foo > ip link add hsr1 netns foo type hsr slave1 eth0 slave2 eth1 > ip netns exec foo ip link ls hsr1 > > => eth0 and eth1 are took from the current netns (because in the code, src_net > is the current netns) but hsr1 is built in netns foo. > > Now, the question is: does HSR really work across netns? Why is the flag > NETIF_F_NETNS_LOCAL set? > dev_forward_skb() may be used to forward an skbuff to another netns. Here is the code snippet that sets NETIF_F_NETNS_LOCAL: /* Not sure about this. Taken from bridge code. netdev_features.h says * it means "Does not change network namespaces". */ dev->features |= NETIF_F_NETNS_LOCAL; HSR is a bit like a bridge since it forwards packets between interfaces on the same Ethernet network, and the bridge code sets NETIF_F_NETNS_LOCAL. And that's really all the reason for the inclusion of the flag - i.e. it should be removed if it doesn't make sense. So, does it make sense? I'm not sure exactly, but I don't think it makes sense to have slaves that are in different namespaces - they are supposed to be part of the same ethernet network after all. But maybe having the HSR interface in a different namespace than the two slaves could make sense - this way you could force an application to only communicate using the HSR protocol, and not use any of the slave interfaces directly. If you agree with the above, then I guess that means NETIF_F_NETNS_LOCAL should not be set? > Note, that I got a panic when playing with hsr: > ip link add hsr1 type hsr slave1 eth1 slave2 eth0 > ip link del hsr1 > => panic > > I dig a bit: > 1/ hsr_netdev_notify() supposes that the port will always be available when the > notification is for an hsr interface. It's wrong. For example, > netdev_wait_allrefs() may resend NETDEV_UNREGISTER. > 2/ with a patch that ignores the notification when the port is NULL, I got a > refcnt problem: > [ 327.372099] unregister_netdevice: waiting for hsr1 to become free. Usage count = -1 Thanks for the bug report! I'll take a look at it ASAP. -- Arvid Brodin | Consultant (Linux) ALTEN | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden arvid.brodin@xxxxxxxx | www.alten.se/en/ -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
