OpenVZ Forum - RDF feed
type: channel
items: [patch 1/4] Network namespaces: cleanup of dev_base list use
items: [patch 2/4] Network namespaces: cleanup of dev_base list use
items: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
items: Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
items: Re: [RFC][patch 1/4] Network namespaces: cleanup of dev_base list use
items: Re: [patch 1/4] Network namespaces: cleanup of dev_base list use
items: [RFC] Network namespaces a path to mergable code.
items: Re: Network namespaces a path to mergable code.
items: Re: [RFC] Network namespaces a path to mergable code.

[patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: Cleanup of dev_base list use, with the aim to make device list per-namespace. In almost every occasion, use of dev_base variable and dev->next pointer could be easily replaced by for_each_netdev loop. A few most complicated places were converted to using first_netdev()/next_netdev(). Signed-off-by: Andrey Savochkin <saw@swsoft.com> --- arch/s390/appldata/appldata_net_sum.c | 2 arch/sparc64/solaris/ioctl.c | 2 drivers/block/aoe/aoecmd.c | 8 ++- drivers/net/wireless/strip.c | 4 - drivers/parisc/led.c | 2 include/linux/netdevice.h | 28 +++++++++++-- net/8021q/vlan.c | 4 - net/8021q/vlanproc.c | 10 ++-- net/bridge/br_if.c | 4 - net/bridge/br_ioctl.c | 4 + net/bridge/br_netlink.c | 3 - net/core/dev.c | 70 ++++++++++++---------------------- net/core/dev_mcast.c | 4 - net/core/rtnetlink.c | 18 ++++---- net/decnet/af_decnet.c | 11 +++-- net/decnet/dn_dev.c | 17 ++++---- net/decnet/dn_fib.c | 2 net/decnet/dn_route.c | 12 ++--- net/ipv4/devinet.c | 15 ++++--- net/ipv4/igmp.c | 25 +++++++----- net/ipv6/addrconf.c | 28 ++++++++----- net/ipv6/anycast.c | 22 ++++++---- net/ipv6/mcast.c | 20 +++++---- net/llc/llc_core.c | 7 ++- net/netrom/nr_route.c | 4 - net/rose/rose_route.c | 8 ++- net/sched/sch_api.c | 8 ++- net/sctp/protocol.c | 2 net/tipc/eth_media.c | 12 +++-- 29 files changed, 200 insertions, 156 deletions --- ./arch/s390/appldata/appldata_net_sum.c.vedevbase Mon Mar 20 08:53:29 2006 +++ ./arch/s390/appldata/appldata_net_sum.c Thu Jun 22 12:03:07 2006 @@ -108,7 +108,7 @@ static void appldata_get_net_sum_data(vo tx_dropped = 0; collisions = 0; read_lock(&dev_base_lock); - for (dev = dev_base; dev != NULL; dev = dev->next) { + for_each_netdev(dev) { if (dev->get_stats == NULL) { continue; } --- ./arch/sparc64/solaris/ioctl.c.vedevbase Mon Mar 20 08:53:29 2006 +++ ./arch/sparc64/solaris/ioctl.c Thu Jun 22 12:03:07 2006 @@ -686,7 +686,7 @@ static inline int solaris_i(unsigned int int i = 0; read_lock_bh(&dev_base_lock); - for (d = dev_base; d; d = d->next) i++; + for_each_netd…
creator: Andrey Savochkin
date: 2006-06-26T09:49:45-00:00

[patch 2/4] Network namespaces: cleanup of dev_base list use
type: item
description: CONFIG_NET_NS and net_namespace structure are introduced. List of network devices is made per-namespace. Each namespace gets its own loopback device. Task's net_namespace pointer is not incorporated into nsproxy structure, since current namespace changes temporarily for processing of packets in softirq. Signed-off-by: Andrey Savochkin <saw@swsoft.com> --- drivers/net/loopback.c | 70 +++++++++++-------- include/linux/init_task.h | 9 ++ include/linux/net_ns.h | 88 ++++++++++++++++++++++++ include/linux/netdevice.h | 20 ++++- include/linux/nsproxy.h | 3 include/linux/sched.h | 3 kernel/nsproxy.c | 14 +++ net/Kconfig | 7 + net/core/dev.c | 162 +++++++++++++++++++++++++++++++++++++++++++++- net/core/net-sysfs.c | 24 ++++++ net/ipv4/devinet.c | 2 net/ipv6/addrconf.c | 2 net/ipv6/route.c | 3 13 files changed, 371 insertions, 36 deletions --- ./drivers/net/loopback.c.venshd Wed Jun 21 18:50:39 2006 +++ ./drivers/net/loopback.c Fri Jun 23 11:48:09 2006 @@ -196,42 +196,56 @@ static struct ethtool_ops loopback_ethto .set_tso = ethtool_op_set_tso, }; -struct net_device loopback_dev = { - .name = "lo", - .mtu = (16 * 1024) + 20 + 20 + 12, - .hard_start_xmit = loopback_xmit, - .hard_header = eth_header, - .hard_header_cache = eth_header_cache, - .header_cache_update = eth_header_cache_update, - .hard_header_len = ETH_HLEN, /* 14 */ - .addr_len = ETH_ALEN, /* 6 */ - .tx_queue_len = 0, - .type = ARPHRD_LOOPBACK, /* 0x0001*/ - .rebuild_header = eth_rebuild_header, - .flags = IFF_LOOPBACK, - .features = NETIF_F_SG | NETIF_F_FRAGLIST +struct net_device loopback_dev_static; +EXPORT_SYMBOL(loopback_dev_static); + +void loopback_dev_dtor(struct net_device *dev) +{ + if (dev->priv) { + kfree(dev->priv); + dev->priv = NULL; + } + free_netdev(dev); +} + +void loopback_dev_ctor(struct net_device *dev) +{ + struct net_device_stats *stats; + + memset(dev, 0, sizeof(*dev)); + strcpy(dev->name, "lo"); + dev->mtu = (16 * 1024) + 20 + 20 + 12; + dev->hard_start_xmit = loopback_xmit; + dev->hard_he…
creator: Andrey Savochkin
date: 2006-06-26T09:52:50-00:00

[patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: Structures related to IPv4 rounting (FIB and routing cache) are made per-namespace. Signed-off-by: Andrey Savochkin <saw@swsoft.com> --- include/linux/net_ns.h | 9 +++ include/net/flow.h | 3 + include/net/ip_fib.h | 62 ++++++++++++++++++++----- net/core/dev.c | 7 ++ net/ipv4/Kconfig | 4 - net/ipv4/fib_frontend.c | 87 +++++++++++++++++++++++++++++------ net/ipv4/fib_hash.c | 13 ++++- net/ipv4/fib_rules.c | 114 +++++++++++++++++++++++++++++++++++++++++------ net/ipv4/fib_semantics.c | 104 +++++++++++++++++++++++++++++------------- net/ipv4/route.c | 26 ++++++++++ 10 files changed, 348 insertions, 81 deletions --- ./include/linux/net_ns.h.vensrt Fri Jun 23 11:49:42 2006 +++ ./include/linux/net_ns.h Fri Jun 23 11:50:16 2006 @@ -14,7 +14,16 @@ struct net_namespace { atomic_t active_ref, use_ref; struct list_head dev_base; struct net_device *loopback; +#ifndef CONFIG_IP_MULTIPLE_TABLES + struct fib_table *fib4_local_table, *fib4_main_table; +#else + struct fib_table **fib4_tables; + struct hlist_head fib4_rules; +#endif + struct hlist_head *fib4_hash, *fib4_laddrhash; + unsigned fib4_hash_size, fib4_info_cnt; unsigned int hash; + char destroying; struct execute_work destroy_work; }; --- ./include/net/flow.h.vensrt Wed Jun 21 18:51:08 2006 +++ ./include/net/flow.h Fri Jun 23 11:50:16 2006 @@ -78,6 +78,9 @@ struct flowi { #define fl_icmp_type uli_u.icmpt.type #define fl_icmp_code uli_u.icmpt.code #define fl_ipsec_spi uli_u.spi +#ifdef CONFIG_NET_NS + struct net_namespace *net_ns; +#endif } __attribute__((__aligned__(BITS_PER_LONG/8))); #define FLOW_DIR_IN 0 --- ./include/net/ip_fib.h.vensrt Wed Jun 21 18:53:17 2006 +++ ./include/net/ip_fib.h Fri Jun 23 11:50:16 2006 @@ -18,6 +18,7 @@ #include <net/flow.h> #include <linux/seq_file.h> +#include <linux/net_ns.h> /* WARNING: The ordering of these elements must match ordering * of RTA_* rtnetlink attribute numbers. @@ -169,14 +170,21 @@ struct fib_table { #ifndef CONFIG_IP_MULTIPLE_TABLES -extern struct fib_table *ip_fib_local_t…
creator: Andrey Savochkin
date: 2006-06-26T09:54:27-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: Andrey Savochkin wrote: > Structures related to IPv4 rounting (FIB and routing cache) > are made per-namespace. How do you handle ICMP_REDIRECT ?
creator: Daniel Lezcano
date: 2006-06-26T14:56:46-00:00

Re: [RFC][patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: Andrey Savochkin <saw@swsoft.com> writes: > Cleanup of dev_base list use, with the aim to make device list per-namespace. > In almost every occasion, use of dev_base variable and dev->next pointer > could be easily replaced by for_each_netdev loop. > A few most complicated places were converted to using > first_netdev()/next_netdev(). As a proof of concept patch this is ok. As a real world patch this is much too big, which prevents review. Plus it takes a few actions that are more than replace just iterators through the device list. In addition I suspect several if not all of these iterators can be replaced with the an appropriate helper function. The normal structure for a patch like this would be to introduce the new helper function. for_each_netdev. And then to replace all of the users while cc'ing the maintainers of those drivers. With each different driver being a different patch. There is another topic for discussion in this patch as well. How much of the context should be implicit and how much should be explicit. If the changes from netchannels had already been implemented, and all of the network processing was happening in a process context then I would trivially agree that implicit would be the way to go. However short of always having code always execute in the proper context I'm not comfortable with implicit parameters to functions. Not that this the contents of this patch should address this but the later patches should. When I went through this, my patchset just added an explicit continue if the devices was not in the appropriate namespace. I actually prefer the multiple list implementation but at the same time I think it is harder to get a clean implementation out of it. Eric > --- ./drivers/block/aoe/aoecmd.c.vedevbase Wed Jun 21 18:50:28 2006 > +++ ./drivers/block/aoe/aoecmd.c Thu Jun 22 12:03:07 2006 > @@ -204,14 +204,17 @@ aoecmd_cfg_pkts(ushort aoemajor, unsigne > sl = sl_tail = NULL; > > read_lock(&dev_base_lock); > - for (ifp = dev_base; ifp; de…
creator: ebiederm
date: 2006-06-26T15:13:52-00:00

Re: [patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: Hi Eric, On Mon, Jun 26, 2006 at 09:13:52AM -0600, Eric W. Biederman wrote: > Andrey Savochkin <saw@swsoft.com> writes: > > > Cleanup of dev_base list use, with the aim to make device list per-namespace. > > In almost every occasion, use of dev_base variable and dev->next pointer > > could be easily replaced by for_each_netdev loop. > > A few most complicated places were converted to using > > first_netdev()/next_netdev(). > > As a proof of concept patch this is ok. > > As a real world patch this is much too big, which prevents review. > Plus it takes a few actions that are more than replace just > iterators through the device list. dev_base list is historically not the cleanest part of Linux networking. I've still spotted a place where the first device in dev_base list is assumed to be loopback. In early days we had more, now only one place or two... > > In addition I suspect several if not all of these iterators > can be replaced with the an appropriate helper function. > > The normal structure for a patch like this would be to > introduce the new helper function. for_each_netdev. > And then to replace all of the users while cc'ing the > maintainers of those drivers. With each different > driver being a different patch. > > There is another topic for discussion in this patch as well. > How much of the context should be implicit and how much > should be explicit. > > If the changes from netchannels had already been implemented, and all of > the network processing was happening in a process context then I would > trivially agree that implicit would be the way to go. Why would we want all network processing happen in a process context? > > However short of always having code always execute in the proper > context I'm not comfortable with implicit parameters to functions. > Not that this the contents of this patch should address this but the > later patches should. We just have too many layers in networking code, and FIB/routing illustrates it well. > > When I went th…
creator: Andrey Savochkin
date: 2006-06-26T15:42:05-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: On Mon, Jun 26, 2006 at 04:56:46PM +0200, Daniel Lezcano wrote: > Andrey Savochkin wrote: > > Structures related to IPv4 rounting (FIB and routing cache) > > are made per-namespace. > > How do you handle ICMP_REDIRECT ? Are you talking about routing cache entries created on incoming redirects? Or outgoing redirects? Andrey
creator: Andrey Savochkin
date: 2006-06-26T15:46:25-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: Andrey Savochkin wrote: > On Mon, Jun 26, 2006 at 04:56:46PM +0200, Daniel Lezcano wrote: > >>Andrey Savochkin wrote: >> >>>Structures related to IPv4 rounting (FIB and routing cache) >>>are made per-namespace. >> >>How do you handle ICMP_REDIRECT ? > > > Are you talking about routing cache entries created on incoming redirects? > Or outgoing redirects? > > Andrey incoming redirects
creator: Daniel Lezcano
date: 2006-06-26T15:57:01-00:00

Re: [patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: Andrey Savochkin <saw@swsoft.com> writes: > Hi Eric, > > On Mon, Jun 26, 2006 at 09:13:52AM -0600, Eric W. Biederman wrote: >> Andrey Savochkin <saw@swsoft.com> writes: >> >> > Cleanup of dev_base list use, with the aim to make device list > per-namespace. >> > In almost every occasion, use of dev_base variable and dev->next pointer >> > could be easily replaced by for_each_netdev loop. >> > A few most complicated places were converted to using >> > first_netdev()/next_netdev(). >> >> As a proof of concept patch this is ok. >> >> As a real world patch this is much too big, which prevents review. >> Plus it takes a few actions that are more than replace just >> iterators through the device list. > > dev_base list is historically not the cleanest part of Linux networking. > I've still spotted a place where the first device in dev_base list is assumed > to be loopback. In early days we had more, now only one place or two... I agree. I'm just saying this should be several patches in a patchset not just one big one. >> In addition I suspect several if not all of these iterators >> can be replaced with the an appropriate helper function. >> >> The normal structure for a patch like this would be to >> introduce the new helper function. for_each_netdev. >> And then to replace all of the users while cc'ing the >> maintainers of those drivers. With each different >> driver being a different patch. >> >> There is another topic for discussion in this patch as well. >> How much of the context should be implicit and how much >> should be explicit. >> >> If the changes from netchannels had already been implemented, and all of >> the network processing was happening in a process context then I would >> trivially agree that implicit would be the way to go. > > Why would we want all network processing happen in a process context? The basic idea is that an interrupt comes in. A light weigh classifier looks at the packet and throws it into the appropriate socket packet queue. Beyond th…
creator: ebiederm
date: 2006-06-26T16:26:23-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: On Mon, Jun 26, 2006 at 05:57:01PM +0200, Daniel Lezcano wrote: > Andrey Savochkin wrote: > > On Mon, Jun 26, 2006 at 04:56:46PM +0200, Daniel Lezcano wrote: > >> > >>How do you handle ICMP_REDIRECT ? > > > > > > Are you talking about routing cache entries created on incoming redirects? > > Or outgoing redirects? > > > > incoming redirects They are inserted into routing cache with the current namespace tag, in the same way as input routing cache entries. Andrey
creator: Andrey Savochkin
date: 2006-06-26T19:39:09-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: On Mon, Jun 26, 2006 at 04:56:46PM +0200, Daniel Lezcano wrote: > Andrey Savochkin wrote: > >Structures related to IPv4 rounting (FIB and routing cache) > >are made per-namespace. > > How do you handle ICMP_REDIRECT ? and btw. how do you handle the beloved 'ping' (i.e. ICMP_ECHO_REQUEST/REPLY for and from guests? best, Herbert
creator: Herbert Poetzl
date: 2006-06-26T20:05:14-00:00

Re: [patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: Eric, On Mon, Jun 26, 2006 at 10:26:23AM -0600, Eric W. Biederman wrote: > Andrey Savochkin <saw@swsoft.com> writes: > > > On Mon, Jun 26, 2006 at 09:13:52AM -0600, Eric W. Biederman wrote: > >> > >> There is another topic for discussion in this patch as well. > >> How much of the context should be implicit and how much > >> should be explicit. > >> > >> If the changes from netchannels had already been implemented, and all of > >> the network processing was happening in a process context then I would > >> trivially agree that implicit would be the way to go. > > > [snip] > It is a big enough problem that I don't think we want to gate on > that development but we need to be ready to take advantage of it when > it happens. Well, ok, implicit namespace reference will take advantage of it if it happens. > > >> However short of always having code always execute in the proper > >> context I'm not comfortable with implicit parameters to functions. > >> Not that this the contents of this patch should address this but the > >> later patches should. > > > > We just have too many layers in networking code, and FIB/routing > > illustrates it well. > > I don't follow this comment. How does a lot of layers affect > the choice of implicit or explicit parameters? If you are maintaining > a patch outside the kernel I could see how there could be a win for > touching the least amount of code possible but for merged code that > you only have to go through once I don't see how the number of layers > affects things. I agree that implicit vs explicit parameters is a topic for discussion. >From what you see from my patch, I vote for implicit ones in this case :) I was talking about layers because they imply changing more code, and usually imply adding more parameters to functions and passing these additional parameters to next layers. In "routing" code it goes from routing entry points, to routing cache, to general FIB functions, to table-specific code (FIB hash). These additional paramet…
creator: Andrey Savochkin
date: 2006-06-26T20:14:37-00:00

Re: [patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: Andrey Savochkin <saw@swsoft.com> writes: > Eric, > > On Mon, Jun 26, 2006 at 10:26:23AM -0600, Eric W. Biederman wrote: >> >> > [snip] >> It is a big enough problem that I don't think we want to gate on >> that development but we need to be ready to take advantage of it when >> it happens. > > Well, ok, implicit namespace reference will take advantage of it > if it happens. And if fact in that case we don't have to do anything special because the process pointer will always be correct. >> >> However short of always having code always execute in the proper >> >> context I'm not comfortable with implicit parameters to functions. >> >> Not that this the contents of this patch should address this but the >> >> later patches should. >> > >> > We just have too many layers in networking code, and FIB/routing >> > illustrates it well. >> >> I don't follow this comment. How does a lot of layers affect >> the choice of implicit or explicit parameters? If you are maintaining >> a patch outside the kernel I could see how there could be a win for >> touching the least amount of code possible but for merged code that >> you only have to go through once I don't see how the number of layers >> affects things. > > I agree that implicit vs explicit parameters is a topic for discussion. > From what you see from my patch, I vote for implicit ones in this case :) Yes. I tend to be against implicit namespaces references mostly because the explicit ones tend to make the code clearer. > I was talking about layers because they imply changing more code, > and usually imply adding more parameters to functions and passing these > additional parameters to next layers. > In "routing" code it goes from routing entry points, to routing cache, to > general FIB functions, to table-specific code (FIB hash). Yes. Although as I recall you don't have to pass anything down very far. Because most functions once you have done the table lookup operate on just a subset of the table, when they are getting th…
creator: ebiederm
date: 2006-06-26T21:02:49-00:00

Re: [RFC][patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: >>Cleanup of dev_base list use, with the aim to make device list per-namespace. >>In almost every occasion, use of dev_base variable and dev->next pointer >>could be easily replaced by for_each_netdev loop. >>A few most complicated places were converted to using >>first_netdev()/next_netdev(). > > > As a proof of concept patch this is ok. > > As a real world patch this is much too big, which prevents review. > Plus it takes a few actions that are more than replace just > iterators through the device list. Mmm, actually it is a whole changeset and should go as a one patch. I didn't find it to be big and my review took only 5-10mins.. I also don't think that mailing each driver maintainer is a good idea. Only if we want to make some buzz :) Kirill
creator: dev
date: 2006-06-27T06:59:33-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: On Mon, Jun 26, 2006 at 10:05:14PM +0200, Herbert Poetzl wrote: > On Mon, Jun 26, 2006 at 04:56:46PM +0200, Daniel Lezcano wrote: > > Andrey Savochkin wrote: > > >Structures related to IPv4 rounting (FIB and routing cache) > > >are made per-namespace. > > > > How do you handle ICMP_REDIRECT ? > > and btw. how do you handle the beloved 'ping' > (i.e. ICMP_ECHO_REQUEST/REPLY for and from > guests? I don't need to do anything special. They are just IP packets. If packets are local in the current net namespace, they are delivered to socket or handled by icmp_rcv. Certainly, packet/raw sockets shouldn't see packets they aren't supposed to see. For raw sockets, it implies making socket lookup aware of namespaces, exactly like for TCP or UDP. Andrey
creator: Andrey Savochkin
date: 2006-06-27T09:25:32-00:00

Re: [RFC][patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: Kirill Korotaev <dev@sw.ru> writes: >>>Cleanup of dev_base list use, with the aim to make device list per-namespace. >>>In almost every occasion, use of dev_base variable and dev->next pointer >>>could be easily replaced by for_each_netdev loop. >>>A few most complicated places were converted to using >>>first_netdev()/next_netdev(). >> As a proof of concept patch this is ok. >> As a real world patch this is much too big, which prevents review. >> Plus it takes a few actions that are more than replace just >> iterators through the device list. > Mmm, actually it is a whole changeset and should go as a one patch. I didn't > find it to be big and my review took only 5-10mins.. > I also don't think that mailing each driver maintainer is a good idea. > Only if we want to make some buzz :) Thanks for supporting my case. You reviewed it and missed the obvious typo. I do agree that a patchset doing it all should happen at once. As for not mailing the maintainers of the code we are changing. That would just be irresponsible. Eric
creator: ebiederm
date: 2006-06-27T11:13:28-00:00

Re: [RFC][patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: >>>>Cleanup of dev_base list use, with the aim to make device list per-namespace. >>>>In almost every occasion, use of dev_base variable and dev->next pointer >>>>could be easily replaced by for_each_netdev loop. >>>>A few most complicated places were converted to using >>>>first_netdev()/next_netdev(). >>> >>>As a proof of concept patch this is ok. >>>As a real world patch this is much too big, which prevents review. >>>Plus it takes a few actions that are more than replace just >>>iterators through the device list. >> >>Mmm, actually it is a whole changeset and should go as a one patch. I didn't >>find it to be big and my review took only 5-10mins.. >>I also don't think that mailing each driver maintainer is a good idea. >>Only if we want to make some buzz :) > > > Thanks for supporting my case. You reviewed it and missed the obvious typo. > I do agree that a patchset doing it all should happen at once. This doesn't support anything. e.g. I caught quite a lot of bugs after Ingo Molnar, but this doesn't make his code "poor". People are people. Anyway, I would be happy to see the typo. > As for not mailing the maintainers of the code we are changing. That > would just be irresponsible. Kirill
creator: dev
date: 2006-06-27T15:08:37-00:00

Re: [RFC][patch 1/4] Network namespaces: cleanup of dev_base list use
type: item
description: Kirill Korotaev <dev@sw.ru> writes: > This doesn't support anything. e.g. I caught quite a lot of bugs after Ingo > Molnar, but this doesn't make his code "poor". People are people. > Anyway, I would be happy to see the typo. Look up thread. You replied to the message where I commented on it. There are two ways to argue this. - It is the linux kernel development style to do small simple obviously patches that copy the maintainer of the code you are changing. - Explain why that is the style. The basic idea is that on a simple patch that is well described, it is trivial to check and trivial to verify. Eric
creator: ebiederm
date: 2006-06-27T16:54:45-00:00

[RFC] Network namespaces a path to mergable code.
type: item
description: Thinking about this I am going to suggest a slightly different direction for get a patchset we can merge. First we concentrate on the fundamentals. - How we mark a device as belonging to a specific network namespace. - How we mark a socket as belonging to a specific network namespace. As part of the fundamentals we add a patch to the generic socket code that by default will disable it for protocol families that do not indicate support for handling network namespaces, on a non-default network namespace. I think that gives us a path that will allow us to convert the network stack one protocol family at a time instead of in one big lump. Stubbing off the sysfs and sysctl interfaces in the first round for the non-default namespaces as you have done should be good enough. The reason for the suggestion is that most of the work for the protocol stacks ipv4 ipv6 af_packet af_unix is largely noise, and simple replacement without real design work happening. Mostly it is just tweaking the code to remove global variables, and doing a couple lookups. Eric
creator: ebiederm
date: 2006-06-27T17:20:40-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Eric, On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote: > > Thinking about this I am going to suggest a slightly different direction > for get a patchset we can merge. > > First we concentrate on the fundamentals. > - How we mark a device as belonging to a specific network namespace. > - How we mark a socket as belonging to a specific network namespace. I agree with the direction of your thoughts. I was trying to do a similar thing, define clear steps in network namespace merging. My first patchset covers devices but not sockets. The only difference from what you're suggesting is ipv4 routing. For me, it is not less important than devices and sockets. May be even more important, since routing exposes design deficiencies less obvious at socket level. > > As part of the fundamentals we add a patch to the generic socket code > that by default will disable it for protocol families that do not indicate > support for handling network namespaces, on a non-default network namespace. Fine Can you summarize you objections against my way of handling devices, please? And what was the typo you referred to in your letter to Kirill Korotaev? Regards Andrey
creator: Andrey Savochkin
date: 2006-06-27T17:58:59-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Andrey Savochkin wrote: > On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote: > >> Thinking about this I am going to suggest a slightly different direction >> for get a patchset we can merge. >> >> First we concentrate on the fundamentals. >> - How we mark a device as belonging to a specific network namespace. >> - How we mark a socket as belonging to a specific network namespace. >> > > I agree with the direction of your thoughts. > I was trying to do a similar thing, define clear steps in network > namespace merging. > > My first patchset covers devices but not sockets. > The only difference from what you're suggesting is ipv4 routing. > For me, it is not less important than devices and sockets. May be even > more important, since routing exposes design deficiencies less obvious at > socket level. > It sounds then like it would be a good start to have general socket namespaces, if it would merge more easily - perhaps then network device namespaces would fall into place more easily. AIUI socket namespaces are also necessary for situations where you want containers to share IP addresses. AIUI, PlanetLab do something like this with a module atop of VServer already (but read http://openvz.org/pipermail/devel/2006-June/000666.html for a proper explanation from Mark Huang) >> As part of the fundamentals we add a patch to the generic socket code >> that by default will disable it for protocol families that do not indicate >> support for handling network namespaces, on a non-default network namespace. >> > > Fine > > Can you summarize you objections against my way of handling devices, please? > There were many objections, the major one being the patch was too large for certainty of adequate review. Quoting what I perceived as a summary from Eric: > When I went through this, my patchset just added an explicit > continue if the devices was not in the appropriate namespace. > I actually prefer the multiple list implementation but at > the same time I think it …
creator: Sam Vilain
date: 2006-06-27T22:20:39-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Andrey Savochkin <saw@swsoft.com> writes: > Eric, > > On Tue, Jun 27, 2006 at 11:20:40AM -0600, Eric W. Biederman wrote: >> >> Thinking about this I am going to suggest a slightly different direction >> for get a patchset we can merge. >> >> First we concentrate on the fundamentals. >> - How we mark a device as belonging to a specific network namespace. >> - How we mark a socket as belonging to a specific network namespace. > > I agree with the direction of your thoughts. > I was trying to do a similar thing, define clear steps in network > namespace merging. > > My first patchset covers devices but not sockets. > The only difference from what you're suggesting is ipv4 routing. > For me, it is not less important than devices and sockets. May be even > more important, since routing exposes design deficiencies less obvious at > socket level. I agree we need to do it. I mostly want a base that allows us to not need to convert the whole network stack at once and still be able to merge code all the way to the stable kernel. The routing code is important for understanding design choices. It isn't important for merging if that makes sense. For everyone looking at routing choices the IPv6 routing table is interesting because it does not use a hash table, and seems quite possibly to be an equally fast structure that scales better. There is something to think about there. >> As part of the fundamentals we add a patch to the generic socket code >> that by default will disable it for protocol families that do not indicate >> support for handling network namespaces, on a non-default network namespace. > > Fine > > Can you summarize you objections against my way of handling devices, please? > And what was the typo you referred to in your letter to Kirill Korotaev? I have no fundamental objects to the content I have seen so far. Please read the first email Kirill responded too. I quoted a couple of sections of code and described the bugs I saw with the patch. All minor things. The…
creator: ebiederm
date: 2006-06-28T04:20:32-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Sam Vilain <sam@vilain.net> writes: > It sounds then like it would be a good start to have general socket > namespaces, if it would merge more easily - perhaps then network device > namespaces would fall into place more easily. I guess I really see both sockets and devices as the fundamental entities of a network namespace. Sockets need to be tagged because in the general case there is no guarantee that a socket that you are using was created in the network namespace of your current process. In general it is possible to get file descriptors opened by someone else because unix domain sockets allow file descriptor passing. Similarly I think there are cases in both unshare and fork that allows you to sockets open before you entered a namespace. Since you can't create a new socket in a different network namespace I can't see any real problems with allowing them to be used, but they are something to be careful about in container creation code. Something to examine here is that if both network devices and sockets are tagged does that still allow implicit network namespace passing. Eric
creator: ebiederm
date: 2006-06-28T04:33:48-00:00

Re: Network namespaces a path to mergable code.
type: item
description: On Tue, Jun 27, 2006 at 10:33:48PM -0600, Eric W. Biederman wrote: > > Something to examine here is that if both network devices and sockets > are tagged does that still allow implicit network namespace passing. I think avoiding implicit network namespace passing expresses more power/flexibility plus it would make things clearer to what container/namespace a given network resource belongs too. >From our experience with an implementation of network containers [Virtual Routing for ipv4/ipv6, with a complete isolation between containers where ip addresses can overlap...], there is some problem domain in which you cannot afford to duplicate a process/daemon in each container [a big process for instance, scalability w.r.t. number of containers etc] By having a proper namespace tag per socket, this can be solved by allowing a process running in the host context to create sockets in that namespace than moving them to the target guest namespaces [via a special setsockopt for instance or unix domain socket as you said]. Regards > > Eric > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
creator: abdallah.chatila
date: 2006-06-28T05:59:18-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Eric W. Biederman wrote: > In general it is possible to get file descriptors opened by someone > else because unix domain sockets allow file descriptor passing. Similarly > I think there are cases in both unshare and fork that allows you to sockets > open before you entered a namespace. > This is an interesting point; it is known to be possible to do this on a traditional system, because with a Unix Domain socket, the other end is always in the same Unix Domain. However what we're doing is saying that, well, the other end of the socket might not be in the same Unix Domain. In fact, we've already smashed to pieces this monolithic concept of a Unix Domain, to the point where the other end might be in a different network domain, but is in the same filesystem domain, for instance. Does it get to pass file descriptors through? We would appear to be stretching the definition of "Unix Domain" somewhat if we allow these sockets to exist between network namespaces. Maybe it doesn't matter; this is just a VFS namespace feature/caveat. Sam.
creator: Sam Vilain
date: 2006-06-28T06:19:19-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Sam Vilain <sam@vilain.net> writes: > Eric W. Biederman wrote: >> In general it is possible to get file descriptors opened by someone >> else because unix domain sockets allow file descriptor passing. Similarly >> I think there are cases in both unshare and fork that allows you to sockets >> open before you entered a namespace. >> > > This is an interesting point; it is known to be possible to do this on a > traditional system, because with a Unix Domain socket, the other end is > always in the same Unix Domain. > > However what we're doing is saying that, well, the other end of the > socket might not be in the same Unix Domain. In fact, we've already > smashed to pieces this monolithic concept of a Unix Domain, to the point > where the other end might be in a different network domain, but is in > the same filesystem domain, for instance. Does it get to pass file > descriptors through? Despite what it might look like unix domain sockets do not live in the filesystem. They store a cookie in the filesystem that roughly corresponds to the port number of an AF_INET socket. When you open a socket the lookup is done by the cookie retrieved from the filesystem. So except for their cookies unix domain sockets are always in the network stack. Which means it is a royal pain to create a unix domain socket between namespaces. Which is the generally desired behavior. > We would appear to be stretching the definition of "Unix Domain" > somewhat if we allow these sockets to exist between network namespaces. > Maybe it doesn't matter; this is just a VFS namespace feature/caveat. Unless I am mistaken this is something that can only be created (given my describe semantics) when you create the container. So if you want it you got it but you can't create it if you never had it. Eric
creator: ebiederm
date: 2006-06-28T06:55:25-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Eric W. Biederman wrote: > Despite what it might look like unix domain sockets do not live in the > filesystem. They store a cookie in the filesystem that roughly > corresponds to the port number of an AF_INET socket. When you open a > socket the lookup is done by the cookie retrieved from the filesystem. unix domain socket lookup uses a path_lookup for sockets in the filesystem namespace and a find_by_name for socket in the abstract namespace. > So except for their cookies unix domain sockets are always in the > network stack. what is that cookie ? the file dentry and mnt ref ? so, ok, the resulting struct sock is part of the network namespace but there is a bridge with the filesystem namespace which does not prevent other namespaces to do a lookup. the lookup routine needs to be changed, this is any way necessary for the abstract namespace. I think we're reaching the limits of namespaces. It would be much easier with a container id in each kernel object we want to isolate. C.
creator: Cedric Le Goater
date: 2006-06-28T09:54:58-00:00

Re: [RFC] Network namespaces a path to mergable code.
type: item
description: Hello, Eric W. Biederman wrote: > Thinking about this I am going to suggest a slightly different direction > for get a patchset we can merge. > > First we concentrate on the fundamentals. > - How we mark a device as belonging to a specific network namespace. > - How we mark a socket as belonging to a specific network namespace. > > As part of the fundamentals we add a patch to the generic socket code > that by default will disable it for protocol families that do not indicate > support for handling network namespaces, on a non-default network namespace. > > I think that gives us a path that will allow us to convert the network stack > one protocol family at a time instead of in one big lump. > > Stubbing off the sysfs and sysctl interfaces in the first round for the > non-default namespaces as you have done should be good enough. > > The reason for the suggestion is that most of the work for the protocol > stacks ipv4 ipv6 af_packet af_unix is largely noise, and simple > replacement without real design work happening. Mostly it is just > tweaking the code to remove global variables, and doing a couple > lookups. How that proposal differs from the initial Daniel's patchset ? how far was that patchset to reach a similar agreement ? OK, i wear blue socks :), but I'm not advocating a patchset more than another i'm just looking for a shorter path. thanks, C.
creator: Cedric Le Goater
date: 2006-06-28T10:20:50-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Hi Eric, On Tue, Jun 27, 2006 at 10:20:32PM -0600, Eric W. Biederman wrote: > Andrey Savochkin <saw@swsoft.com> writes: [snip] > > My first patchset covers devices but not sockets. > > The only difference from what you're suggesting is ipv4 routing. > > For me, it is not less important than devices and sockets. May be even > > more important, since routing exposes design deficiencies less obvious at > > socket level. > > I agree we need to do it. I mostly want a base that allows us to > not need to convert the whole network stack at once and still be able > to merge code all the way to the stable kernel. > > The routing code is important for understanding design choices. It > isn't important for merging if that makes sense. Ok, fine. Now I'm working on socket code. We still have a question about implicit vs explicit function parameters. This question becomes more important for sockets: if we want to allow to use sockets belonging to namespaces other than the current one, we need to do something about it. One possible option to resolve this question is to show 2 relatively short patches just introducing namespaces for sockets in 2 ways: with explicit function parameters and using implicit current context. Then people can compare them and vote. Do you think it's worth the effort? > > For everyone looking at routing choices the IPv6 routing table is > interesting because it does not use a hash table, and seems quite > possibly to be an equally fast structure that scales better. > > There is something to think about there. Sure [snip] > > > > Can you summarize you objections against my way of handling devices, please? > > And what was the typo you referred to in your letter to Kirill Korotaev? > > I have no fundamental objects to the content I have seen so far. > > Please read the first email Kirill responded too. I quoted a couple > of sections of code and described the bugs I saw with the patch. I found your comments, thank you! > > All minor things. The typo I was re…
creator: Andrey Savochkin
date: 2006-06-28T11:06:05-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: Daniel Lezcano wrote: > Andrey Savochkin wrote: > >> Structures related to IPv4 rounting (FIB and routing cache) >> are made per-namespace. Hi Andrey, if the ressources are private to the namespace, how do you will handle NFS mounted before creating the network namespace ? Do you take care of that or simply assume you can't access NFS anymore ? Regards -Daniel
creator: Daniel Lezcano
date: 2006-06-28T13:51:32-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Cedric Le Goater <clg@fr.ibm.com> writes: > Eric W. Biederman wrote: > >> Despite what it might look like unix domain sockets do not live in the >> filesystem. They store a cookie in the filesystem that roughly >> corresponds to the port number of an AF_INET socket. When you open a >> socket the lookup is done by the cookie retrieved from the filesystem. > > unix domain socket lookup uses a path_lookup for sockets in the filesystem > namespace and a find_by_name for socket in the abstract namespace. Right. And the abstract namespace does nothing with the current filesystem. >> So except for their cookies unix domain sockets are always in the >> network stack. > > what is that cookie ? the file dentry and mnt ref ? The socket entry in the filesystem but really the socket inode number in that entry. This entry has nothing to with dentry's or mount refs so if I read the correctly every path to that socket should yield the same entry. > so, ok, the resulting struct sock is part of the network namespace but > there is a bridge with the filesystem namespace which does not prevent > other namespaces to do a lookup. the lookup routine needs to be changed, > this is any way necessary for the abstract namespace. Yep. > I think we're reaching the limits of namespaces. It would be much easier > with a container id in each kernel object we want to isolate. Nope. Except for the fact that names are peculiar (sockets, network device names, IP address, routes...) the network stack splits quite cleanly. I did all of this in a proof of concept mode several months ago and the code is still sitting in my git tree on kernel.org. I even got the generic stack reference counting fixed. Eric
creator: ebiederm
date: 2006-06-28T14:03:41-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > > I think we're reaching the limits of namespaces. It would be much easier > > with a container id in each kernel object we want to isolate. > > Nope. Except for the fact that names are peculiar (sockets, network > device names, IP address, routes...) the network stack splits quite cleanly. > > I did all of this in a proof of concept mode several months ago and > the code is still sitting in my git tree on kernel.org. I even got > the generic stack reference counting fixed. > > Eric Which branch?
creator: serue
date: 2006-06-28T14:15:39-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: On Wed, Jun 28, 2006 at 03:51:32PM +0200, Daniel Lezcano wrote: > Daniel Lezcano wrote: > >Andrey Savochkin wrote: > > > >>Structures related to IPv4 rounting (FIB and routing cache) > >>are made per-namespace. > > Hi Andrey, > > if the ressources are private to the namespace, how do you will > handle NFS mounted before creating the network namespace ? > Do you take care of that or simply assume you can't access NFS anymore ? considering that many providers put their guests on NFS (or similar) filers, and run them on nodes (for distributing the CPU load), that is indeed an interesting question ... what will happen to AOE or iSCSI btw? best, Herbert > Regards > > -Daniel
creator: Herbert Poetzl
date: 2006-06-28T14:19:12-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: Daniel, On Wed, Jun 28, 2006 at 03:51:32PM +0200, Daniel Lezcano wrote: > Daniel Lezcano wrote: > > Andrey Savochkin wrote: > > > >> Structures related to IPv4 rounting (FIB and routing cache) > >> are made per-namespace. > > Hi Andrey, > > if the ressources are private to the namespace, how do you will handle > NFS mounted before creating the network namespace ? Do you take care of > that or simply assume you can't access NFS anymore ? This is a question that brings up another level of interaction between networking and the rest of kernel code. Solution that I use now makes the NFS communication part always run in the root namespace. This is discussable, of course, but it's a far more complicated matter than just device lists or routing :) Best regards Andrey
creator: Andrey Savochkin
date: 2006-06-28T14:30:15-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: >>>>Structures related to IPv4 rounting (FIB and routing cache) >>>>are made per-namespace. >> >>Hi Andrey, >> >>if the ressources are private to the namespace, how do you will handle >>NFS mounted before creating the network namespace ? Do you take care of >>that or simply assume you can't access NFS anymore ? > > > This is a question that brings up another level of interaction between > networking and the rest of kernel code. > Solution that I use now makes the NFS communication part always run in > the root namespace. This is discussable, of course, but it's a far more > complicated matter than just device lists or routing :) if we had containers (not namespaces) then it would be also possible to run NFS in context of the appropriate container and thus each user could mount NFS itself with correct networking context. it's another thing which ties subsytems and makes namespaces ugly :/ Kirill
creator: dev
date: 2006-06-28T14:34:33-00:00

Re: Network namespaces a path to mergable code.
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: > Quoting Eric W. Biederman (ebiederm@xmission.com): >> > I think we're reaching the limits of namespaces. It would be much easier >> > with a container id in each kernel object we want to isolate. >> >> Nope. Except for the fact that names are peculiar (sockets, network >> device names, IP address, routes...) the network stack splits quite cleanly. >> >> I did all of this in a proof of concept mode several months ago and >> the code is still sitting in my git tree on kernel.org. I even got >> the generic stack reference counting fixed. >> >> Eric > > Which branch? It should be the proof-of-concept branch. It is a development branch so the history is ugly but the result was fairly decent. Eric
creator: ebiederm
date: 2006-06-28T14:56:26-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: Daniel Lezcano <dlezcano@fr.ibm.com> writes: > Daniel Lezcano wrote: >> Andrey Savochkin wrote: >> >>> Structures related to IPv4 rounting (FIB and routing cache) >>> are made per-namespace. > > Hi Andrey, > > if the ressources are private to the namespace, how do you will handle NFS > mounted before creating the network namespace ? Through the filesystem namespace. It is a weird case but it works :) > Do you take care of that or simply assume you can't access NFS anymore ? It is actually a noop. Unless I goofed this is basically handled by looking at which socket NFS is using to communicate, and plucking the namespace from there. As I recall NFS gets the socket at mount time when it still has user space context available. So regardless if I implemented it correctly you can implement it that way and always get the namespace context from whoever implemented it. Eric
creator: ebiederm
date: 2006-06-28T15:05:50-00:00

Re: [RFC] Network namespaces a path to mergable code.
type: item
description: Cedric Le Goater <clg@fr.ibm.com> writes: > How that proposal differs from the initial Daniel's patchset ? how far was > that patchset to reach a similar agreement ? My impression is as follows. The OpenVz implementation and mine work on the same basic principles of handling the network stack at layer 2. We have our implementation differences but the core ideas are about the same. Daniels patch still had elements of layer 3 handling as I recall and that has problems. > OK, i wear blue socks :), but I'm not advocating a patchset more than > another i'm just looking for a shorter path. Besides laying the foundations. The current conversation seems to be about understanding the implications of the network stack when we implement a network namespace. There is a lot to the networking stack so it takes a while. In addition this is one part of the problem that everyone has implemented, so we have several more opinions on how it should be done and what needs to happen. Eric
creator: ebiederm
date: 2006-06-28T15:20:26-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Andrey Savochkin <saw@swsoft.com> writes: > Ok, fine. > Now I'm working on socket code. > > We still have a question about implicit vs explicit function parameters. > This question becomes more important for sockets: if we want to allow to use > sockets belonging to namespaces other than the current one, we need to do > something about it. There seems to be some real benefit to that. Especially for things like NFS, that captures the context at mount time. It might as well keep the namespace in it's socket. > One possible option to resolve this question is to show 2 relatively short > patches just introducing namespaces for sockets in 2 ways: with explicit > function parameters and using implicit current context. > Then people can compare them and vote. > Do you think it's worth the effort? Given that we have two strong opinions in different directions I think it is worth the effort to resolve this. In a slightly different vein your second patch introduced a lot of #ifdef CONFIG_NET_NS in C files. That is something we need to look closely at. So I think the abstraction that we use to access per network namespace variables needs some work if we are going to allow the ability to compile out all of the namespace code. The explicit versus implicit lookup is just one dimension of that problem. >> All minor things. The typo I was referring to was a section where the >> original iteration was on an ifp variable and you called it dev >> without changing the rest of the code in that section. >> >> The only big issue was that the patch too big, and should be split >> into a patchset for better review. One patch for the new functions, >> and the an additional patch for each driver/subsystem hunk describing >> why that chunk needed to be changed. > > I'll split the patch. Thanks. >> I'm still curious why many of those chunks can't use existing helper >> functions, to be cleaned up. > > What helper functions are you referring to? Basically most of the device list walker functions…
creator: ebiederm
date: 2006-06-28T16:51:26-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: Kirill Korotaev wrote: >>>>> Structures related to IPv4 rounting (FIB and routing cache) >>>>> are made per-namespace. >>> >>> >>> Hi Andrey, >>> >>> if the ressources are private to the namespace, how do you will >>> handle NFS mounted before creating the network namespace ? Do you >>> take care of that or simply assume you can't access NFS anymore ? >> >> >> >> This is a question that brings up another level of interaction between >> networking and the rest of kernel code. >> Solution that I use now makes the NFS communication part always run in >> the root namespace. This is discussable, of course, but it's a far more >> complicated matter than just device lists or routing :) > > if we had containers (not namespaces) then it would be also possible to > run NFS in context of the appropriate container and thus each user could > mount NFS itself with correct networking context. I was asking the question because in some case, we want a lightweight container for running applications (aka application container) who need to share the filesystem and it will be too bad to have a network namespace which brings isolation and prevents to implement application containers. By the way, I agree from a point of view of a system container, a complete network isolation is perfect. Regards. Daniel.
creator: Daniel Lezcano
date: 2006-06-28T16:56:55-00:00

Re: [patch 3/4] Network namespaces: IPv4 FIB/routing in namespaces
type: item
description: Daniel Lezcano wrote: > Kirill Korotaev wrote: > >>>>>> Structures related to IPv4 rounting (FIB and routing cache) >>>>>> are made per-namespace. >>>> >>>> >>>> >>>> Hi Andrey, >>>> >>>> if the ressources are private to the namespace, how do you will >>>> handle NFS mounted before creating the network namespace ? Do you >>>> take care of that or simply assume you can't access NFS anymore ? >>> >>> >>> >>> >>> This is a question that brings up another level of interaction between >>> networking and the rest of kernel code. >>> Solution that I use now makes the NFS communication part always run in >>> the root namespace. This is discussable, of course, but it's a far more >>> complicated matter than just device lists or routing :) >> >> >> if we had containers (not namespaces) then it would be also possible >> to run NFS in context of the appropriate container and thus each user >> could mount NFS itself with correct networking context. With a relatively small patch, I was able to make NFS bind to a particular local IP (poor man's namespace with existing code). I also changed it so that multiple mounts to the same destination (and with unique local mount points) are treated as unique mounts. This patch was done so that I could stress test NFS servers, but similar logic might work for namespace isolation as well... Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com
creator: Ben Greear
date: 2006-06-28T17:10:14-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Hi Eric, On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote: > Andrey Savochkin <saw@swsoft.com> writes: > > > One possible option to resolve this question is to show 2 relatively short > > patches just introducing namespaces for sockets in 2 ways: with explicit > > function parameters and using implicit current context. > > Then people can compare them and vote. > > Do you think it's worth the effort? > > Given that we have two strong opinions in different directions I think it > is worth the effort to resolve this. Do you have time to extract necessary parts of your old patch? Or you aren't afraid of letting me draft an alternative version of socket namespaces basing on your code? :) > > In a slightly different vein your second patch introduced a lot > of #ifdef CONFIG_NET_NS in C files. That is something we need to look closely > at. > > So I think the abstraction that we use to access per network namespace > variables needs some work if we are going to allow the ability to compile > out all of the namespace code. The explicit versus implicit lookup is just > one dimension of that problem. This is a good comment. Those ifdef's mostly correspond to places where we walk over lists and need to filter-out entities not belonging to a specific namespace. Those places about the same in your and my implementation. We can think what we can do with them. One trick that I used on several occasions is net_ns_same macro which doesn't evalute its arguments if CONFIG_NET_NS not defined, and thus can be used without ifdef's. Returning to implicit vs explicit function arguments, I belive that implicit arguments are more promising in having zero impact on the code when CONFIG_NET_NS is disabled. Functions like inet_addr_type will translate into exactly the same code as they did without net namespace patches. > > >> I'm still curious why many of those chunks can't use existing helper > >> functions, to be cleaned up. > > > > What helper functions are you referring to…
creator: Andrey Savochkin
date: 2006-06-28T17:22:40-00:00

Re: Network namespaces a path to mergable code.
type: item
description: On Wed, Jun 28, 2006 at 09:22:40PM +0400, Andrey Savochkin wrote: > Hi Eric, > > On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote: > > Andrey Savochkin <saw@swsoft.com> writes: > > > > > One possible option to resolve this question is to show 2 > > > relatively short patches just introducing namespaces for sockets > > > in 2 ways: with explicit function parameters and using implicit > > > current context. Then people can compare them and vote. Do you > > > think it's worth the effort? > > > > Given that we have two strong opinions in different directions I > > think it is worth the effort to resolve this. > > Do you have time to extract necessary parts of your old patch? Or you > aren't afraid of letting me draft an alternative version of socket > namespaces basing on your code? :) > > > In a slightly different vein your second patch introduced a lot of > > #ifdef CONFIG_NET_NS in C files. That is something we need to look > > closely at. > > > > So I think the abstraction that we use to access per network > > namespace variables needs some work if we are going to allow the > > ability to compile out all of the namespace code. The explicit > > versus implicit lookup is just one dimension of that problem. > This is a good comment. > > Those ifdef's mostly correspond to places where we walk over lists and > need to filter-out entities not belonging to a specific namespace. > Those places about the same in your and my implementation. We can > think what we can do with them. One trick that I used on several > occasions is net_ns_same macro which doesn't evalute its arguments if > CONFIG_NET_NS not defined, and thus can be used without ifdef's. yes, I think almost all of those cases can be avoided while making the code even more readable by using proper preprocessor (or even inline) mechanisms > Returning to implicit vs explicit function arguments, I belive that > implicit arguments are more promising in having zero impact on the > code when CONFIG_NET_N…
creator: Herbert Poetzl
date: 2006-06-28T17:40:06-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Andrey Savochkin <saw@swsoft.com> writes: >> A general pattern that happens in cleanups is the discovery >> that code using an old interface in a problematic way really >> could be done much better another way. I didn't dig enough >> to see if that was the case in any of the code that you changed. > > Well, there is obvious improvement of this kind: many protocols walk over > device list to find devices with non-NULL protocol specific pointers. > For example, IPv6, decnet and others do it on module unloading to clean up. > Those places just ask for some simpler standard way of doing it, but I wasn't > bold enough for such radical change. > Do you think I should try? It probably makes sense to asses that after the patches are split up. Unless you run into something obvious. Eric
creator: ebiederm
date: 2006-06-28T17:50:00-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Andrey Savochkin <saw@swsoft.com> writes: >> In a slightly different vein your second patch introduced a lot >> of #ifdef CONFIG_NET_NS in C files. That is something we need to look closely >> at. >> >> So I think the abstraction that we use to access per network namespace >> variables needs some work if we are going to allow the ability to compile >> out all of the namespace code. The explicit versus implicit lookup is just >> one dimension of that problem. > > This is a good comment. > > Those ifdef's mostly correspond to places where we walk over lists > and need to filter-out entities not belonging to a specific namespace. > Those places about the same in your and my implementation. > We can think what we can do with them. > One trick that I used on several occasions is net_ns_same macro > which doesn't evalute its arguments if CONFIG_NET_NS not defined, > and thus can be used without ifdef's. > > Returning to implicit vs explicit function arguments, I belive that implicit > arguments are more promising in having zero impact on the code when > CONFIG_NET_NS is disabled. > Functions like inet_addr_type will translate into exactly the same code as > they did without net namespace patches. Which brings us to a basic question. Does it make sense to have a define that completely disables namespace support. I know all of the simple namespaces have been implemented like that, and it was relatively easy there. I'm not at all certain in the long term we want a configuration option. Especially if simply enabling the code doesn't have an impact on performance. Which I think is a merge requirement anyway. As for inet_addr_type and friends I do agree that implicit arguments make for an easier implementation of CONFIG_NET_NS. My gut feel is though that the code with explicit arguments is probably more comprehensible in the long term. Especially as we find more weird exceptions where the process we are running in does not have the correct network namespace. In general unnecess…
creator: ebiederm
date: 2006-06-28T18:11:24-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Andrey Savochkin <saw@swsoft.com> writes: > Hi Eric, > > On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote: >> Andrey Savochkin <saw@swsoft.com> writes: >> >> > One possible option to resolve this question is to show 2 relatively short >> > patches just introducing namespaces for sockets in 2 ways: with explicit >> > function parameters and using implicit current context. >> > Then people can compare them and vote. >> > Do you think it's worth the effort? >> >> Given that we have two strong opinions in different directions I think it >> is worth the effort to resolve this. > > Do you have time to extract necessary parts of your old patch? > Or you aren't afraid of letting me draft an alternative version of socket > namespaces basing on your code? :) I'm not terribly afraid. I can always say you did it wrong. :) I don't think I am going to have time today. But since this conversation is slowing down and we are to getting into the technical details. I will try and find some time. Eric
creator: ebiederm
date: 2006-06-28T18:14:41-00:00

Re: Network namespaces a path to mergable code.
type: item
description: On Wed, Jun 28, 2006 at 12:14:41PM -0600, Eric W. Biederman wrote: > Andrey Savochkin <saw@swsoft.com> writes: > > > On Wed, Jun 28, 2006 at 10:51:26AM -0600, Eric W. Biederman wrote: > >> Andrey Savochkin <saw@swsoft.com> writes: > >> > >> > One possible option to resolve this question is to show 2 relatively short > >> > patches just introducing namespaces for sockets in 2 ways: with explicit > >> > function parameters and using implicit current context. > >> > Then people can compare them and vote. > >> > Do you think it's worth the effort? > >> > >> Given that we have two strong opinions in different directions I think it > >> is worth the effort to resolve this. > > > > Do you have time to extract necessary parts of your old patch? > > Or you aren't afraid of letting me draft an alternative version of socket > > namespaces basing on your code? :) > > I'm not terribly afraid. I can always say you did it wrong. :) :) > I don't think I am going to have time today. But since this conversation > is slowing down and we are to getting into the technical details. > I will try and find some time. Good. I'll focus on my part then. Andrey
creator: Andrey Savochkin
date: 2006-06-28T18:51:36-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Andrey Savochkin wrote: > Ok, fine. > Now I'm working on socket code. > > We still have a question about implicit vs explicit function parameters. > This question becomes more important for sockets: if we want to allow to use > sockets belonging to namespaces other than the current one, we need to do > something about it. > > One possible option to resolve this question is to show 2 relatively short > patches just introducing namespaces for sockets in 2 ways: with explicit > function parameters and using implicit current context. > Then people can compare them and vote. > Do you think it's worth the effort? > The attached patch can have some part interesting for you for the socket tagging. It is in the IPV4 isolation (part 5/6). With this and the private routing table you will probably have a good IPV4 isolation.
creator: Daniel Lezcano
date: 2006-06-28T21:53:42-00:00

Re: Network namespaces a path to mergable code.
type: item
description: On Wed, 28 Jun 2006, Daniel Lezcano wrote: > The attached patch can have some part interesting for you for the socket > tagging. It is in the IPV4 isolation (part 5/6). With this and the private > routing table you will probably have a good IPV4 isolation. Please send patches inline, do not attach them. (Perhaps we should have a filter on vger which drops emails with attachements). All of this needs to be done in a way where it can be entirely disabled at compile time, so there is zero overhead for people who don't want network namespaces. - James -- James Morris <jmorris@namei.org>
creator: James Morris
date: 2006-06-28T22:54:22-00:00

Re: Network namespaces a path to mergable code.
type: item
description: James Morris <jmorris@namei.org> writes: > On Wed, 28 Jun 2006, Daniel Lezcano wrote: > >> The attached patch can have some part interesting for you for the socket >> tagging. It is in the IPV4 isolation (part 5/6). With this and the private >> routing table you will probably have a good IPV4 isolation. > > Please send patches inline, do not attach them. > > (Perhaps we should have a filter on vger which drops emails with > attachements). > > All of this needs to be done in a way where it can be entirely disabled at > compile time, so there is zero overhead for people who don't want > network namespaces. I agree with the principle of no overhead. The goal is an implementation that has no measurable overhead when there is only one network namespace. If that goal is achieved and you can compile in the network namespace code and not measure overhead there should be no need for a compile time option. Eric
creator: ebiederm
date: 2006-06-29T00:19:05-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Daniel Lezcano <dlezcano@fr.ibm.com> writes: > Andrey Savochkin wrote: > >> Ok, fine. >> Now I'm working on socket code. >> We still have a question about implicit vs explicit function parameters. >> This question becomes more important for sockets: if we want to allow to use >> sockets belonging to namespaces other than the current one, we need to do >> something about it. >> One possible option to resolve this question is to show 2 relatively short >> patches just introducing namespaces for sockets in 2 ways: with explicit >> function parameters and using implicit current context. >> Then people can compare them and vote. >> Do you think it's worth the effort? >> > > The attached patch can have some part interesting for you for the socket > tagging. It is in the IPV4 isolation (part 5/6). With this and the private > routing table you will probably have a good IPV4 isolation. > This patch partially isolates ipv4 by adding the network namespace > structure in the structure sock, bind bucket and skbuf. Ugh. skbuf sounds very wrong. Per packet overhead? > When a socket > is created, the pointer to the network namespace is stored in the > struct sock and the socket belongs to the namespace by this way. That > allows to identify sockets related to a namespace for lookup and > procfs. > > The lookup is extended with a network namespace pointer, in > order to identify listen points binded to the same port. That allows > to have several applications binded to INADDR_ANY:port in different > network namespace without conflicting. The bind is checked against > port and network namespace. Yes. If we don't duplicate the hash table we need to extend the lookup. > When an outgoing packet has the loopback destination addres, the > skbuff is filled with the network namespace. So the loopback packets > never go outside the namespace. This approach facilitate the migration > of loopback because identification is done by network namespace and > not by address. The loopback has been be…
creator: ebiederm
date: 2006-06-29T00:25:40-00:00

Re: Network namespaces a path to mergable code.
type: item
description: Eric W. Biederman wrote: >>When an outgoing packet has the loopback destination addres, the >>skbuff is filled with the network namespace. So the loopback packets >>never go outside the namespace. This approach facilitate the migration >>of loopback because identification is done by network namespace and >>not by address. The loopback has been benchmarked by tbench and the >>overhead is roughly 1.5 % > > > Ugh. 1.5% is noticeable. We will see with all private network namespace ... > > I think it is cheaper to have one loopback device per namespace. > Which removes the need for a skbuff tag. Yes, probably.
creator: Daniel Lezcano
date: 2006-06-29T09:42:37-00:00