aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/ppp/ppp_deflate.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2015-01-29 14:20:16 -0800
committerDavid S. Miller <davem@davemloft.net>2015-01-29 14:20:16 -0800
commitd445d63b77577f7ecdd7eb7e9d6518493cdcd778 (patch)
treecff61da52b4a1e3a82ac16c8d8854431a8189b97 /drivers/net/ppp/ppp_deflate.c
parentlib/checksum.c: fix build for generic csum_tcpudp_nofold (diff)
parentvxlan: setup the right link netns in newlink hdlr (diff)
downloadlinux-dev-d445d63b77577f7ecdd7eb7e9d6518493cdcd778.tar.xz
linux-dev-d445d63b77577f7ecdd7eb7e9d6518493cdcd778.zip
Merge branch 'netns'
Nicolas Dichtel says: ==================== netns: audit netdevice creation with IFLA_NET_NS_[PID|FD] When one of these attributes is set, the netdevice is created into the netns pointed by IFLA_NET_NS_[PID|FD] (see the call to rtnl_create_link() in rtnl_newlink()). Let's call this netns the dest_net. After this creation, if the newlink handler exists, it is called with a netns argument that points to the netns where the netlink message has been received (called src_net in the code) which is the link netns. Hence, with one of these attributes, it's possible to create a x-netns netdevice. Here is the result of my code review: - all ip tunnels (sit, ipip, ip6_tunnels, gre[tap][v6], ip_vti[6]) does not really allows to use this feature: the netdevice is created in the dest_net and the src_net is completely ignored in the newlink handler. - VLAN properly handles this x-netns creation. - bridge ignores src_net, which seems fine (NETIF_F_NETNS_LOCAL is set). - CAIF subsystem is not clear for me (I don't know how it works), but it seems to wrongly use src_net. Patch #1 tries to fix this, but it was done only by code review (and only compile-tested), so please carefully review it. I may miss something. - 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. - ieee802154 uses also src_net and does not have NETIF_F_NETNS_LOCAL. Same question: does this netdevice really supports x-netns? - bonding ignores src_net and flag NETIF_F_NETNS_LOCAL is set, ie x-netns is not supported. Fine. - CAN does not support rtnl/newlink, ok. - ipvlan uses src_net and does not have NETIF_F_NETNS_LOCAL. After looking at the code, it seems that this drivers support x-netns. Am I right? - macvlan/macvtap uses src_net and seems to have x-netns support. - team ignores src_net and has the flag NETIF_F_NETNS_LOCAL, ie x-netns is not supported. Ok. - veth uses src_net and have x-netns support ;-) Ok. - VXLAN didn't properly handle this. The link netns (vxlan->net) is the src_net and not dest_net (see patch #2). Note that it was already possible to create a x-netns vxlan before the commit f01ec1c017de ("vxlan: add x-netns support") but the nedevice remains broken. To summarize: - CAIF patch must be carefully reviewed - for HSR, ieee802154, ipvlan: is x-netns supported? ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ppp/ppp_deflate.c')
0 files changed, 0 insertions, 0 deletions