[Devel] Re: [PATCH v2 1/2] nfnetlink: netns support
Patrick McHardy wrote:
> Alexey Dobriyan wrote:
>> Make nfnl socket per-petns.
>
> Applied, thanks.
While merging the nf-next tree with the changes from net-next I noticed
that this patch allows any namespace to send configurations and verdicts
to nfnetlink_{log,queue}. It seems you need to add a check for init_net
to their recv functions unless I'm missing something.
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH] xt_connlimit: netns support
Alexey Dobriyan wrote: Applied, thanks. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: RFC: netfilter: nf_conntrack: add support for "conntrack zones"
jamal wrote: > On Thu, 2010-01-14 at 16:37 +0100, Patrick McHardy wrote: >> jamal wrote: > >>> Agreed that this would be a main driver of such a feature. >>> Which means that you need zones (or whatever noun other people use) to >>> work on not just netfilter, but also routing, ipsec etc. >> Routing already works fine. I believe IPsec should also work already, >> but I haven't tried it. > > maybe further discussion would clarify this point.. > >> The zone is set based on some other criteria (in this case the >> incoming device). > > If you are using a netdev as a reference point, then I take it > if you add vlans should be possible to do multiple zones on a single > physical netdev? Or is there some other way to satisfy that? Yes, you can assign a zone to each netdev. macvlan will also work. Using a netfilter target for the raw table might be a better choice on second thought though, it provides more flexibility and avoids the netfilter-specific device setting. I'll probably change that. >> The packets make one pass through the stack >> to a veth device and are SNATed in POSTROUTING to non-clashing >> addresses. > > Ok - makes sense. > i.e NAT would work; and policy routing as well as arp would be fine. > Also it looks to be sufficiently useful to fit a specific use case you > are interested in. > But back to my question on routing, ipsec etc (and you may not be > interested in solving this problem, but it is what i was getting to > earlier). Lets take for example: > a) network tables like SAD/SPD tables: how you would separate those on a > per-zone basis? i.e 10.0.0.1/zone1 could use different > policy/association than 10.0.0.1/zone2 The selectors include an ifindex, which could be used to distinguish both based on the interface. > b) dynamic protocols (routing, IKE etc): how do you do that without > making both sides understand what is going on? In case of IPsec the outer addresses are different, its only the selectors which will have similar addresses. A keying deamon should have no trouble with this. The ifindex would be needed in the selectors though to make sure each policy is used for the correct traffic. A routing daemon is unrealistic to be used in this scenario, at least a single one for all the overlapping networks. >>> This is a valid concern against the namespace approach. Existing tools >>> of course could be taught to know about namespaces - and one could >>> argue that if you can resolve the overlap IP address issue, then you >>> _have to_ modify user space anyways. >> I don't think thats true. > > Refer to my statements above for an example. > >> In any case its completely impractical >> to modify every userspace tool that does something with networking >> and potentially make complex configuration changes to have all >> those namespaces interact nicely. > > Agreed. But the major ones like iproute2 etc could be taught. We have > namespaces in the kernel already, over a period of time I think changing > the user space tools would a sensible evolution. Yes, that might be useful in any case. But I don't think it would even work for iproute or other standalone programs, a process can't associate to an existing namespace except through clone(). So it needs to run as child of a process already associated with the namespace. >> Currently they are simply not >> very well suited for virtualizing selected parts of networking. > > My contention is that it is a lot less headache to just virtualize > all the network stack and then use what you want than it is to go and > selectively changing the network objects. > Note: if i wanted today i could run racoon on every namespace > unchanged and it would work or i could modify racoon to understand > namespaces... See above. >> I'm not sure whether there is a typical user for overlapping >> networks :) I know of setups with ~150 overlapping networks. >> >> The number of conntracks per zone doesn't matter since the >> table is shared between all zones. network namespaces would >> allocate 150 tables, each of the same size, which might be >> quite large. > > Thats what i was looking for .. > So the difference, to pick the 150 zones example so as to put a number > around it, is namespaces will consume 150.X bytes (where X is the > overhead of a conntrack table) and you approach will be (X + 152) bytes, > correct? > What is the typical sizeof X? No, to give some correct number. Assuming a conntrack table of 10MB (large, but reasonable depending on the number of connections) we get an overhead of: namespaces: 150 * 10MB memory use "zones": 152 bytes increased cod
[Devel] Re: RFC: netfilter: nf_conntrack: add support for "conntrack zones"
jamal wrote: > Ive had an equivalent discussion with B Greear (CCed) at one point on > something similar, curious if you solve things differently - couldnt > tell from the patch if you address it. Its basically the same, except that this patch uses ct_extend and mark values. > Comments inline: > > On Thu, 2010-01-14 at 15:05 +0100, Patrick McHardy wrote: >> The attached largish patch adds support for "conntrack zones", >> which are virtual conntrack tables that can be used to seperate >> connections from different zones, allowing to handle multiple >> connections with equal identities in conntrack and NAT. >> >> A zone is simply a numerical identifier associated with a network >> device that is incorporated into the various hashes and used to >> distinguish entries in addition to the connection tuples. Additionally >> it is used to seperate conntrack defragmentation queues. An iptables >> target for the raw table could be used alternatively to the network >> device for assigning conntrack entries to zones. >> >> >> This is mainly useful when connecting multiple private networks using >> the same addresses (which unfortunately happens occasionally) > > Agreed that this would be a main driver of such a feature. > Which means that you need zones (or whatever noun other people use) to > work on not just netfilter, but also routing, ipsec etc. Routing already works fine. I believe IPsec should also work already, but I haven't tried it. > As a digression: this is trivial to solve with network namespaces. > >> to pass >> the packets through a set of veth devices and SNAT each network to a >> unique address, after which they can pass through the "main" zone and >> be handled like regular non-clashing packets and/or have NAT applied a >> second time based f.i. on the outgoing interface. >> > > The fundamental question i have is: > how you deal with overlapping addresses? > i.e zone1 uses 10.0.0.1 and zone2 uses 10.0.0.1 but they are for > different NAT users/endpoints. The zone is set based on some other criteria (in this case the incoming device). The packets make one pass through the stack to a veth device and are SNATed in POSTROUTING to non-clashing addresses. When they come out of the other side of the veth device, they make a second pass through the network stack and can be handled like any other packet. So the setup would be (with 10.0.0.0/24 on if0 and if1): ip rule add from if0 lookup t0 ip route add default veth0 table t0 iptables -t nat -A POSTROUTING -o veth0 -j NETMAP --to 10.1.0.0/24 echo 1 >/sys/class/net/if0/nf_ct_zone echo 1 >/sys/class/net/veth0/nf_ct_zone ip rule add from if1 lookup t1 ip route add default veth2 table t0 iptables -t nat -A POSTROUTING -o veth2 -j NETMARK --to 10.1.1.0/24 etho 2 >/sys/class/net/if1/nf_ct_zone echo 2 >/sys/class/net/veth2/nf_ct_zone The mapped packets are received on veth1 and veth3 with non-clashing addresses. >> As probably everyone has noticed, this is quite similar to what you >> can do using network namespaces. The main reason for not using >> network namespaces is that its an all-or-nothing approach, you can't >> virtualize just connection tracking. > > Unless there is a clever approach for overlapping IP addresses (my > question above), i dont see a way around essentially virtualizing the > whole stack which clone(CLONE_NEWNET) provides.. I don't understand the problem. >> Beside the difficulties in >> managing different namespaces from f.i. an IKE or PPP daemon running >> in the initial namespace, > > This is a valid concern against the namespace approach. Existing tools > of course could be taught to know about namespaces - and one could > argue that if you can resolve the overlap IP address issue, then you > _have to_ modify user space anyways. I don't think thats true. In any case its completely impractical to modify every userspace tool that does something with networking and potentially make complex configuration changes to have all those namespaces interact nicely. Currently they are simply not very well suited for virtualizing selected parts of networking. >> network namespaces have a quite large >> overhead, especially when used with a large conntrack table. > > Elaboration needed. > You said the size in 64 bit increases to 152B per conntrack i think? I said code size increases by 152b. > Do you have a hand-wave figure we can use as a metric to elaborate this > point? What would a typical user of this feature have in number of > "zones" and how many contracks per zone? Actually we could also look > at extremes (huge number vs low numbers)... I'm not sure whether ther
[Devel] RFC: netfilter: nf_conntrack: add support for "conntrack zones"
The attached largish patch adds support for "conntrack zones",
which are virtual conntrack tables that can be used to seperate
connections from different zones, allowing to handle multiple
connections with equal identities in conntrack and NAT.
A zone is simply a numerical identifier associated with a network
device that is incorporated into the various hashes and used to
distinguish entries in addition to the connection tuples. Additionally
it is used to seperate conntrack defragmentation queues. An iptables
target for the raw table could be used alternatively to the network
device for assigning conntrack entries to zones.
This is mainly useful when connecting multiple private networks using
the same addresses (which unfortunately happens occasionally) to pass
the packets through a set of veth devices and SNAT each network to a
unique address, after which they can pass through the "main" zone and
be handled like regular non-clashing packets and/or have NAT applied a
second time based f.i. on the outgoing interface.
Something like this, with multiple tunl and veth devices, each pair
using a unique zone:
|
PREROUTING
|
FORWARD
|
POSTROUTING: SNAT to unique network
|
|
PREROUTING
|
FORWARD
|
POSTROUTING: SNAT to eth0 address
|
As probably everyone has noticed, this is quite similar to what you
can do using network namespaces. The main reason for not using
network namespaces is that its an all-or-nothing approach, you can't
virtualize just connection tracking. Beside the difficulties in
managing different namespaces from f.i. an IKE or PPP daemon running
in the initial namespace, network namespaces have a quite large
overhead, especially when used with a large conntrack table.
I'm not too fond of this partial feature duplication myself, but I
couldn't think of a better way to do this without the downsides of
using namespaces. Having partially shared network namespaces would
be great, but it doesn't seem to fit in the design very well.
I'm open for any better suggestion :)
A couple of notes on the patch:
- its not entirely finished yet (ctnetlink and xt_connlimit are
missing), I wanted to have a discussion about the general idea first.
- the patch uses ct_extend to avoid increasing the connection tracking
entry size when this feature is not used. An older version of this
patch adds the zone identifier to the conntrack tuples. This greatly
simplifies the changes to the code since the zone doesn't has to
passed around (something like 40 lines total), but has the downside
of increasing the tuple size.
- the overhead should be quite small, its mainly the extra argument
passing and an occasional extra comparison. Code size increase with
all netfilter options enabled on x86_64 is 152 bytes.
Any comments welcome.
commit 7f68e7aa55f9e1f9dfd647b60dace4149f27ae1f
Author: Patrick McHardy
Date: Thu Jan 14 13:51:06 2010 +0100
netfilter: nf_conntrack: add support for "conntrack zones"
Normally, each connection needs a unique identity. Conntrack zones allow
to specify a numerical zone for each interface, connections in different
zones can use the same identity.
Signed-off-by: Patrick McHardy
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index a3fccc8..6e6a209 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -953,6 +953,10 @@ struct net_device {
/* max exchange id for FCoE LRO by ddp */
unsigned int fcoe_ddp_xid;
#endif
+
+#ifdef CONFIG_NF_CONNTRACK_ZONES
+ u16 nf_ct_zone;
+#endif
};
#define to_net_dev(d) container_of(d, struct net_device, dev)
diff --git a/include/net/ip.h b/include/net/ip.h
index 85108cf..61aface 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -336,8 +336,11 @@ enum ip_defrag_users {
IP_DEFRAG_LOCAL_DELIVER,
IP_DEFRAG_CALL_RA_CHAIN,
IP_DEFRAG_CONNTRACK_IN,
+ __IP_DEFRAG_CONNTRACK_IN_END = IP_DEFRAG_CONNTRACK_IN + 0x,
IP_DEFRAG_CONNTRACK_OUT,
+ __IP_DEFRAG_CONNTRACK_OUT_END = IP_DEFRAG_CONNTRACK_OUT + 0x,
IP_DEFRAG_CONNTRACK_BRIDGE_IN,
+ __IP_DEFRAG_CONNTRACK_BRIDGE_IN = IP_DEFRAG_CONNTRACK_BRIDGE_IN + 0x,
IP_DEFRAG_VS_IN,
IP_DEFRAG_VS_OUT,
IP_DEFRAG_VS_FWD
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index ccab594..b82a68d 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -353,8 +353,11 @@ struct inet_frag_queue;
enum ip6_defrag_users {
IP6_DEFRAG_LOCAL_DELIVER,
IP6_DEFRAG_CONNTRACK_IN,
+ __IP6_DEFRAG_CONNTRACK_IN = IP6_DEFRAG_CONNTRACK_IN + 0x,
IP6_DEFRAG_CONNTRACK_OUT,
+ __IP6_DEFRAG_CONNTRACK_OUT = IP6_DEFRAG_CONNTRACK_OUT + 0x,
IP6_DEFRAG_CONNTRACK_BRIDGE_IN,
+ __IP6_DEFRAG_CONNTRACK_BRIDGE_IN = IP6_DEFRAG_CONNTRACK_BRIDGE_IN + 0x,
};
struct ip6_create_arg {
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index a0904ad..9488ac6 100644
[Devel] Re: [PATCH v2 2/2] ctnetlink: netns support
Alexey Dobriyan wrote: Also applied, thanks. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v2 1/2] nfnetlink: netns support
Alexey Dobriyan wrote: > Make nfnl socket per-petns. Applied, thanks. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/2] nfnetlink: add netns support
Alexey Dobriyan wrote: > On Wed, Jan 13, 2010 at 02:42:00PM +0100, Patrick McHardy wrote: >> Alexey Dobriyan wrote: >>> On Wed, Jan 13, 2010 at 02:27:08PM +0100, Patrick McHardy wrote: >>>> Alexey Dobriyan wrote: >>>>> On Wed, Jan 13, 2010 at 02:02:33PM +0100, Patrick McHardy wrote: >>>>>> Alexey Dobriyan wrote: >>>>>>> + struct sock *nfnl; >>>>>>> + struct sock *nfnl_stash; >>>>>> Shouldn't this be contained in an ifdef(CONFIG_NETFILTER_NETLINK) >>>>>> (_MODULE) ? >>>>> No, otherwise you won't be able to start using, e. g., nfnetlink_log >>>>> module on NETFILTER_NETLINK=n kernels without reboot. >>>> You mean after enabling CONFIG_NETFILTER_NETLINK? >>> Yes, and it can't be directly enabled, because it's hidden option. >>> >>>> That seems like a pretty poor argument, you have to do a reboot after >>>> changing a lot of config options. >>> It's still a step back if I add #ifdef and a regression if you ask me. >>> The price is only two pointers per-netns. >> Yes, I don't mind much, but I still think this is not an argument >> at all. Whether you have to reboot after changing your configuration >> has never been "stable" and we don't consider it when making changes. > > Perhaps we should start considering it. > > What's bool is bool and fair game. > What's tristate better be fully tristate. That's silly. Any configuration option is allowed to change data structure layout, at which point you'll often need to reboot. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/2] nfnetlink: add netns support
Alexey Dobriyan wrote: > On Wed, Jan 13, 2010 at 02:27:08PM +0100, Patrick McHardy wrote: >> Alexey Dobriyan wrote: >>> On Wed, Jan 13, 2010 at 02:02:33PM +0100, Patrick McHardy wrote: >>>> Alexey Dobriyan wrote: >>>>> + struct sock *nfnl; >>>>> + struct sock *nfnl_stash; >>>> Shouldn't this be contained in an ifdef(CONFIG_NETFILTER_NETLINK) >>>> (_MODULE) ? >>> No, otherwise you won't be able to start using, e. g., nfnetlink_log >>> module on NETFILTER_NETLINK=n kernels without reboot. >> You mean after enabling CONFIG_NETFILTER_NETLINK? > > Yes, and it can't be directly enabled, because it's hidden option. > >> That seems like a pretty poor argument, you have to do a reboot after >> changing a lot of config options. > > It's still a step back if I add #ifdef and a regression if you ask me. > The price is only two pointers per-netns. Yes, I don't mind much, but I still think this is not an argument at all. Whether you have to reboot after changing your configuration has never been "stable" and we don't consider it when making changes. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/2] nfnetlink: add netns support
Alexey Dobriyan wrote: > On Wed, Jan 13, 2010 at 02:02:33PM +0100, Patrick McHardy wrote: >> Alexey Dobriyan wrote: > >>> + struct sock *nfnl; >>> + struct sock *nfnl_stash; >> Shouldn't this be contained in an ifdef(CONFIG_NETFILTER_NETLINK) >> (_MODULE) ? > > No, otherwise you won't be able to start using, e. g., nfnetlink_log > module on NETFILTER_NETLINK=n kernels without reboot. You mean after enabling CONFIG_NETFILTER_NETLINK? That seems like a pretty poor argument, you have to do a reboot after changing a lot of config options. >> The remaining parts look good to me. > > OK, I'll resend shortly. Thanks. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/2] nfnetlink: add netns support
Alexey Dobriyan wrote:
> Make nfnetlink socket per-netns.
>
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -81,6 +81,8 @@ struct net {
> #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
> struct netns_ct ct;
> #endif
> + struct sock *nfnl;
> + struct sock *nfnl_stash;
Shouldn't this be contained in an ifdef(CONFIG_NETFILTER_NETLINK)
(_MODULE) ?
> #endif
> +static void __net_exit nfnetlink_net_exit_batch(struct list_head
> *net_exit_list)
> {
> - printk("Netfilter messages via NETLINK v%s.\n", nfversion);
> + struct net *net;
>
> - nfnl = netlink_kernel_create(&init_net, NETLINK_NETFILTER, NFNLGRP_MAX,
> - nfnetlink_rcv, NULL, THIS_MODULE);
> - if (!nfnl) {
> - printk(KERN_ERR "cannot initialize nfnetlink!\n");
> - return -ENOMEM;
> + list_for_each_entry(net, net_exit_list, exit_list) {
> + rcu_assign_pointer(net->nfnl, NULL);
> + }
> + synchronize_net();
> + list_for_each_entry(net, net_exit_list, exit_list) {
> + netlink_kernel_release(net->nfnl_stash);
> }
No parenthesis around single statements please.
> --- a/net/netfilter/nfnetlink_log.c
> +++ b/net/netfilter/nfnetlink_log.c
> @@ -323,7 +323,7 @@ __nfulnl_send(struct nfulnl_instance *inst)
> NLMSG_DONE,
> sizeof(struct nfgenmsg));
>
> - status = nfnetlink_unicast(inst->skb, inst->peer_pid, MSG_DONTWAIT);
> + status = nfnetlink_unicast(inst->skb, &init_net, inst->peer_pid,
> MSG_DONTWAIT);
Overly long line.
The remaining parts look good to me.
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 2/2] ctnetlink: add netns support
Alexey Dobriyan wrote: > Allow conntrack program to operate correctly in netns. > Note: passing events is not done in this patch. Why not? It seems like a small change and without this the netns support will still be incomplete. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 5/7] netns ebtables: ebtable_filter in netns
Alexey Dobriyan wrote: Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 7/7] netns ebtables: br_nf_pre_routing_finish() fixup
Alexey Dobriyan wrote: Also applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 4/7] netns ebtables: ebtable_broute in netns
Alexey Dobriyan wrote: Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 6/7] netns ebtables: ebtable_nat in netns
Alexey Dobriyan wrote: Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 3/7] netns ebtables: more cleanup during ebt_unregister_table()
Alexey Dobriyan wrote: > Now that ebt_unregister_table() can be called during netns stop, and module > pinning scheme can't prevent netns stop, do table cleanup by hand. > Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 2/7] netns ebtables: part 2
Alexey Dobriyan wrote: > * return ebt_table from ebt_register_table(), module code will save it into > per-netns data for unregistration > * duplicate ebt_table at the very beginning of registration -- it's added into > list, so one ebt_table wouldn't end up in many lists (and each netns has > different one) > * introduce underscored tables in individial modules, this is temporary to not > break bisection. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/7] netns ebtables: part 1
Alexey Dobriyan wrote: > * propagate netns from userspace, register table in passed netns > * remporarily register every ebt_table in init_net > > P. S.: one needs to add ".netns_ok = 1" to igmp_protocol to test with > ebtables(8) in netns. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/7] netns ebtables: part 1
Alexey Dobriyan wrote: > * propagate netns from userspace, register table in passed netns > * remporarily register every ebt_table in init_net > > P. S.: one needs to add ".netns_ok = 1" to igmp_protocol to test with > ebtables(8) in netns. The containers list address bounces and the netfilter address is the user list. Please resend with the proper addresses so other developers get a chance to review the patches. Thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/7] netns ebtables: part 1
Alexey Dobriyan wrote: > On Wed, Oct 15, 2008 at 08:20:14AM +0400, Alexey Dobriyan wrote: >> One needs to add ".netns_ok = 1" to igmp_protocol to test all of this >> with ebtables() in netns. > > Contains 80-column violations, I forgot about damn script again :^) Apart from the minor comment about patch 1 (and the 80 column violations I didn't notice so far :)), these look good to me. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/7] netns ebtables: part 1
Alexey Dobriyan wrote:
One needs to add ".netns_ok = 1" to igmp_protocol to test all of this
with ebtables() in netns.
-
[PATCH 1/7] netns ebtables: part 1
* make list of ebt_tables per-netns
* propagate netns from userspace, register table in passed netns
* temporarily register every ebt_table in init_net
I'm not queuing patches for 2.6.29 yet, please resend the entire
batch once Dave opens his net-next tree again.
--- a/include/net/netns/x_tables.h
+++ b/include/net/netns/x_tables.h
@@ -6,5 +6,6 @@
struct netns_xt {
struct list_head tables[NPROTO];
+ struct list_head ebt_tables;
This could just use tables[NFPROTO_BRIDGE].
BTW, I have a patch queued to change NPROTO to NFPROTO_NUMPROTO in
struct netns_xt since we've decoupled the netfilter values from
generic procotol values (attached in case you would like to add
an ACK).
commit c985d88e7ae4f45d50cca80033429c7270a8c185
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu Oct 16 13:14:26 2008 +0200
netfilter: netns: use NFPROTO_NUMPROTO instead of NUMPROTO for tables array
The netfilter families have been decoupled from regular protocol families.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
diff --git a/include/net/netns/x_tables.h b/include/net/netns/x_tables.h
index 0cb63ed..b809397 100644
--- a/include/net/netns/x_tables.h
+++ b/include/net/netns/x_tables.h
@@ -2,9 +2,9 @@
#define __NETNS_X_TABLES_H
#include
-#include
+#include
struct netns_xt {
- struct list_head tables[NPROTO];
+ struct list_head tables[NFPROTO_NUMPROTO];
};
#endif
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [bug, -git] ERROR: "ebt_unregister_table" [net/bridge/netfilter/ebtable_nat.ko] undefined
Ingo Molnar wrote: > * Patrick McHardy <[EMAIL PROTECTED]> wrote: > >> Ingo Molnar wrote: >>> i think you misunderstood my report. This is about latest upstream -git >>> being broken: >>> >>> ERROR: "ebt_register_table" [net/bridge/netfilter/ebtable_filter.ko] >>> undefined! >>> ERROR: "ebt_do_table" [net/bridge/netfilter/ebtable_filter.ko] undefined! >>> ERROR: "ebt_unregister_table" [net/bridge/netfilter/ebtable_filter.ko] >>> undefined! >>> ERROR: "ebt_register_table" [net/bridge/netfilter/ebtable_broute.ko] >>> undefined! >>> ERROR: "ebt_do_table" [net/bridge/netfilter/ebtable_broute.ko] undefined! >>> ERROR: "ebt_unregister_table" [net/bridge/netfilter/ebtable_broute.ko] >>> undefined! >>> make[1]: *** [__modpost] Error 1 >>> make: *** [modules] Error 2 >>> >> Does this patch fix it? > > yeah, the module build now succeeds fine with that config, thanks > Patrick! > > Tested-by: Ingo Molnar <[EMAIL PROTECTED]> Thanks Ingo, I'll send it upstream tonight. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [bug, -git] ERROR: "ebt_unregister_table" [net/bridge/netfilter/ebtable_nat.ko] undefined
Ingo Molnar wrote: i think you misunderstood my report. This is about latest upstream -git being broken: ERROR: "ebt_register_table" [net/bridge/netfilter/ebtable_filter.ko] undefined! ERROR: "ebt_do_table" [net/bridge/netfilter/ebtable_filter.ko] undefined! ERROR: "ebt_unregister_table" [net/bridge/netfilter/ebtable_filter.ko] undefined! ERROR: "ebt_register_table" [net/bridge/netfilter/ebtable_broute.ko] undefined! ERROR: "ebt_do_table" [net/bridge/netfilter/ebtable_broute.ko] undefined! ERROR: "ebt_unregister_table" [net/bridge/netfilter/ebtable_broute.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 i posted to this thread because i wanted to find a relevant context. (but probably is not) Anyway, i started a new thread for this. the dependencies there look pretty complex so i did not find a quick fix - but i can test patches. This appears to be caused by Jan's Kconfig changes to use menuconfig, which lost a dependency on BRIDGE: -menu "Bridge: Netfilter Configuration" - depends on BRIDGE && BRIDGE_NETFILTER - -config BRIDGE_NF_EBTABLES +menuconfig BRIDGE_NF_EBTABLES tristate "Ethernet Bridge tables (ebtables) support" select NETFILTER_XTABLES help ebtables is a general, extensible frame/packet identification framework. Say 'Y' or 'M' here if you want to do Ethernet filtering/NAT/brouting on the Ethernet bridge. Does this patch fix it? diff --git a/net/bridge/netfilter/Kconfig b/net/bridge/netfilter/Kconfig index 366d3e9..ba6f73e 100644 --- a/net/bridge/netfilter/Kconfig +++ b/net/bridge/netfilter/Kconfig @@ -4,6 +4,7 @@ menuconfig BRIDGE_NF_EBTABLES tristate "Ethernet Bridge tables (ebtables) support" + depends on BRIDGE && BRIDGE_NETFILTER select NETFILTER_XTABLES help ebtables is a general, extensible frame/packet identification ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 33/33] Enable netfilter in netns
Alexey Dobriyan wrote: > On Thu, Oct 02, 2008 at 11:12:08AM +0200, Patrick McHardy wrote: > >> Is there an easy way to test all this stuff? >> > > I used the following: > > 0) netns is currently mutually exclusive with sysfs, so depending on >sanity of distro initscripts booting sysfs-less kernel can be tricky. > >In Gentoo, for example a) rm -rf /sys (sic!), b) RC_USE_FSTAB="yes", >c) RC_DEVICES="static" in /etc/conf.d/rc are needed. > > 1) netns creation tool (attached, some container guy posted it somewhere) > > # ns_exec -n /bin/sh > > 2) shutdown network in init_net > > sudo /etc/init.d/ntpd stop > sudo /etc/init.d/sshd stop > sudo /etc/init.d/iptables stop > sudo /etc/init.d/ip6tables stop > sudo /etc/init.d/net.eth1 stop > sudo /etc/init.d/net.eth0 stop > > 3) move netdevices to netns > > ip l s dev eth0 netns "$1" > ip l s dev eth1 netns "$1" > > where $1 is PID of shell from 1) > > 4) in netns start everything back > > sudo /etc/init.d/net.eth0 start > sudo /etc/init.d/net.eth1 start > sudo /etc/init.d/iptables start > sudo /etc/init.d/ip6tables start > sudo /etc/init.d/sshd start > sudo /etc/init.d/ntpd start > > 5) at this point my usual NAT setup is back working for me and everything > should >be like in init_net (modulo aforementioned exceptions) and >independent from init_net. > > Leaked netns are in /proc/slabinfo under "net_namespace". > > Some IPv6 printks can be annoying, so mute them. > > Object poisoning with SLUB won't work for irrelevant reasons, so use SLAB. > > Something like that. > Thanks, I'll give it a try. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 33/33] Enable netfilter in netns
Alexey Dobriyan wrote: > >From kernel perspective, allow entrance in nf_hook_slow(). > > Stuff which uses nf_register_hook/nf_register_hooks, but otherwise not > netns-ready: > > DECnet netfilter > ipt_CLUSTERIP > nf_nat_standalone.c together with XFRM (?) > IPVS > several individual match modules (like hashlimit) > ctnetlink > NOTRACK > all sorts of queueing and reporting to userspace > L3 and L4 protocol sysctls, bridge sysctls > probably something else > > Anyway critical mass has been achieved, there is no reason to hide netfilter > any longer. > > >From userspace perspective, allow to manipulate all sorts of > > > > > > > iptables/ip6tables/arptables rules. > Applied. thanks Alexey. Is there an easy way to test all this stuff? ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 31/33] netns ct: fixup DNAT in netns
Alexey Dobriyan wrote: Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 32/33] netns nat: PPTP NAT in netns
Alexey Dobriyan wrote: Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 29/33] netns nat: per-netns NAT table
Alexey Dobriyan wrote: > Same story as with iptable_filter, iptables_raw tables. Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 30/33] netns nat: per-netns bysource hash
Alexey Dobriyan wrote: Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 28/33] netns nat: fix ipt_MASQUERADE in netns
Alexey Dobriyan wrote: > First, allow entry in notifier hook. > Second, start conntrack cleanup in netns to which netdevice belongs. Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 29/33] netns nat: per-netns NAT table
Alexey Dobriyan wrote: > Same story as with iptable_filter, iptables_raw tables. > Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 27/33] netns ct: PPTP conntracking in netns
Alexey Dobriyan wrote: Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 26/33] netns ct: GRE conntracking in netns
Alexey Dobriyan wrote: > * make keymap list per-netns > * per-netns keymal lock (not strictly necessary) > * flush keymap at netns stop and module unload. Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 25/33] netns ct: H323 conntracking in netns
Alexey Dobriyan wrote: Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 24/33] netns ct: SIP conntracking in netns
Alexey Dobriyan wrote: Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v2 7/6] netns ct: final netns tweaks
Alexey Dobriyan wrote: > Add init_net checks to not remove kmem_caches twice and so on. > > Refactor functions to split code which should be executed only for > init_net into one place. > > ip_ct_attach and ip_ct_destroy assignments remain separate, because > they're separate stages in setup and teardown. > > NOTE: NOTRACK code is in for-every-net part. It will be made per-netns > after we decidce how to do it correctly. Also applied. thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v2 2/6] netns ct: per-netns /proc/net/stat/nf_conntrack , /proc/net/stat/ip_conntrack
Alexey Dobriyan wrote: > Show correct conntrack count, while I'm at it. Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v2 6/6] netns ct: per-netns conntrack accounting
Alexey Dobriyan wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> > --- > > include/net/netfilter/nf_conntrack_acct.h | 10 +-- > include/net/netns/conntrack.h |2 > net/netfilter/nf_conntrack_acct.c | 100 > +- > net/netfilter/nf_conntrack_core.c |4 - > 4 files changed, 81 insertions(+), 35 deletions(-) > Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v2 4/6] netns ct: per-netns net.netfilter.nf_conntrack_checksum sysctl
Alexey Dobriyan wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> > --- > > include/net/netfilter/nf_conntrack.h |1 - > include/net/netns/conntrack.h |1 + > net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |2 +- > net/ipv4/netfilter/nf_conntrack_proto_icmp.c |2 +- > net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c |2 +- > net/netfilter/nf_conntrack_proto_dccp.c|2 +- > net/netfilter/nf_conntrack_proto_tcp.c |2 +- > net/netfilter/nf_conntrack_proto_udp.c |2 +- > net/netfilter/nf_conntrack_proto_udplite.c |2 +- > net/netfilter/nf_conntrack_standalone.c|7 +++ Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v2 3/6] netns ct: per-netns net.netfilter.nf_conntrack_count sysctl
Alexey Dobriyan wrote: > Note, sysctl table is always duplicated, this is simpler and less > special-cased. > > Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v2 5/6] netns ct: per-netns net.netfilter.nf_conntrack_log_invalid sysctl
Alexey Dobriyan wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> > --- > > include/net/netfilter/nf_conntrack_l4proto.h | 15 +++ > include/net/netns/conntrack.h |1 + > net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |2 +- > net/ipv4/netfilter/nf_conntrack_proto_icmp.c |6 +++--- > net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c |2 +- > net/netfilter/nf_conntrack_core.c |1 - > net/netfilter/nf_conntrack_proto_dccp.c| 10 ++ > net/netfilter/nf_conntrack_proto_tcp.c | 18 ++ > net/netfilter/nf_conntrack_proto_udp.c |6 +++--- > net/netfilter/nf_conntrack_proto_udplite.c |8 > net/netfilter/nf_conntrack_standalone.c|6 +++--- > 11 files changed, 39 insertions(+), 36 deletions(-) Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v2 1/6] netns ct: per-netns statistics
Alexey Dobriyan wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> > --- > > include/net/netfilter/nf_conntrack.h |8 +- > include/net/netns/conntrack.h |1 > net/ipv4/netfilter/nf_conntrack_l3proto_ipv4_compat.c |4 - > net/netfilter/nf_conntrack_core.c | 49 > +- > net/netfilter/nf_conntrack_expect.c |4 - > net/netfilter/nf_conntrack_standalone.c |4 - Applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 17/33] netns ct: final init_net tweaks
Alexey Dobriyan wrote: > Ping! > > I've just sent patch which adds init_net checks in somewhat nicer way. Thanks. > Please, review and apply the rest. I'll do that this week during the netfilter workshop. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 17/33] netns ct: final init_net tweaks
Alexey Dobriyan wrote: > On Tue, Sep 09, 2008 at 09:20:42AM +0200, Patrick McHardy wrote: >> Having multiple of these net_eq checks per function (14 total) is >> not a very nice way to do this. > > Yep, I was just afraid of some subtle ordering rules and to keep > potential init_net breakage to minimum. Me too, but I still prefer to do it properly once. >> How about splitting the code into a netns and a global part instead? > > Prebably they aren't strict at all. Not particulary. For cleanup a three stage approach with 1. init_net deactivation (ip_ct_attach = NULL) 2. generic netns cleanup 3. init_net specific final cleanup (slab cache, nf_conntrack_cachep, accounting, helpers, protocols, ...) should work fine. The initialization should be OK with just a init_net part and a generic netns part. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 17/33] netns ct: final init_net tweaks
Alexey Dobriyan wrote:
> Add checks for init_net to not create kmem caches twice and so on.
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
>
> diff --git a/net/netfilter/nf_conntrack_core.c
> b/net/netfilter/nf_conntrack_core.c
> index b55944e..52d0663 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -1016,7 +1016,8 @@ EXPORT_SYMBOL_GPL(nf_conntrack_flush);
> supposed to kill the mall. */
> void nf_conntrack_cleanup(struct net *net)
> {
> - rcu_assign_pointer(ip_ct_attach, NULL);
> + if (net_eq(net, &init_net))
> + rcu_assign_pointer(ip_ct_attach, NULL);
Having multiple of these net_eq checks per function (14 total) is
not a very nice way to do this. How about splitting the code into
a netns and a global part instead?
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 16/33] netns ct: per-netns event cache
Patrick McHardy wrote: > Alexey Dobriyan wrote: >> On Tue, Sep 09, 2008 at 08:12:27AM +0200, Patrick McHardy wrote: >>> Alexey Dobriyan wrote: >>>> Heh, last minute proof-reading of this patch made me think, >>>> that this is actually unneeded, simply because "ct" pointers will be >>>> different for different conntracks in different netns, just like they >>>> are different in one netns. >>>> >>>> Not so sure anymore. >>> Its necessary because the cache needs to be flushed on netns exit >>> and this is only allowed while its not in use anymore. >>> >>> I don't see anything in this series actually making sure nothing >>> hits the cache on exit though. Am I missing something? >> >> When netns refcount hits zero, netdevices in it will start dropping >> packets. >> And there is synchronize_net() call before cache flush. >> >> I think this is enough. > > Thanks for the explanation, I have a closer look at this. Yes, that looks fine. Applied, thanks. BTW, doesn't __vlan_hwaccel_rx() also needs a netns_alive() check to avoid passing packets to AF_PACKET sockets in dead namespaces? ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 05/33] netns ct: per-netns expectations
Alexey Dobriyan wrote:
> On Tue, Sep 09, 2008 at 07:49:34AM +0200, Patrick McHardy wrote:
>>> @@ -406,7 +404,7 @@ int nf_ct_expect_related(struct nf_conntrack_expect
>>> *expect)
>>> }
>>> }
>>> - if (nf_ct_expect_count >= nf_ct_expect_max) {
>>> + if (net->ct.expect_count >= nf_ct_expect_max) {
>>> if (net_ratelimit())
>>> printk(KERN_WARNING
>>>"nf_conntrack: expectation table full\n");
>> I assume these message are globally visible even with namespaces?
>> Can we make this (and the corresponding ct hash message) refer to
>> the namespace? Otherwise it might be a bit confusing.
>
> This is somewhat peculiar situation.
>
> netns doesn't have unique ID like, say, ifindex.
>
> The only number related to netns is "struct net *". They can be
> distinguised by pointer value, but userspace when does clone(CLONE_NEWNET)
> do not, obviously, control it and after creation doesn't have a way to find
> it out.
>
> And if we print with "%p, net" kernelspace pointer get exposed which is
> not nice.
No, that also wouldn't solve the confusion. I guess conntrack is not
the only subsystem which prints netns related messages, so how about
adding an unique identifier that can be associated by userspace?
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 16/33] netns ct: per-netns event cache
Alexey Dobriyan wrote:
> On Tue, Sep 09, 2008 at 08:12:27AM +0200, Patrick McHardy wrote:
>> Alexey Dobriyan wrote:
>>> Heh, last minute proof-reading of this patch made me think,
>>> that this is actually unneeded, simply because "ct" pointers will be
>>> different for different conntracks in different netns, just like they
>>> are different in one netns.
>>>
>>> Not so sure anymore.
>> Its necessary because the cache needs to be flushed on netns exit
>> and this is only allowed while its not in use anymore.
>>
>> I don't see anything in this series actually making sure nothing
>> hits the cache on exit though. Am I missing something?
>
> When netns refcount hits zero, netdevices in it will start dropping packets.
> And there is synchronize_net() call before cache flush.
>
> I think this is enough.
Thanks for the explanation, I have a closer look at this.
>> Additionally (I might have missed a following patch moving it
>> out though) this doesn't belong in the netns exit path:
>>
>> void nf_conntrack_cleanup(struct net *net)
>> {
>> rcu_assign_pointer(ip_ct_attach, NULL);
>> ...
>> rcu_assign_pointer(nf_ct_destroy, NULL);
>
> This is dealt with in 17/33
>
> Have you got 18/33, archives show it's missing?
There are two patches labeled 17/33, I assume the second one is
actually 18/33.
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 16/33] netns ct: per-netns event cache
Alexey Dobriyan wrote:
> Heh, last minute proof-reading of this patch made me think,
> that this is actually unneeded, simply because "ct" pointers will be
> different for different conntracks in different netns, just like they
> are different in one netns.
>
> Not so sure anymore.
Its necessary because the cache needs to be flushed on netns exit
and this is only allowed while its not in use anymore.
I don't see anything in this series actually making sure nothing
hits the cache on exit though. Am I missing something?
Additionally (I might have missed a following patch moving it
out though) this doesn't belong in the netns exit path:
void nf_conntrack_cleanup(struct net *net)
{
rcu_assign_pointer(ip_ct_attach, NULL);
...
rcu_assign_pointer(nf_ct_destroy, NULL);
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 15/33] netns ct: pass conntrack to nf_conntrack_event_cache() not skb
Alexey Dobriyan wrote: > This is cleaner, we already know conntrack to which event is relevant. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 14/33] netns ct: cleanup after L3 and L4 proto unregister in every netns
Alexey Dobriyan wrote: Applthanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 12/33] netns ct: export netns list
Alexey Dobriyan wrote: > Conntrack code will use it for > a) removing expectations and helpers when corresponding module is removed, and > b) removing conntracks when L3 protocol conntrack module is removed. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 13/33] netns ct: unregister helper in every netns
Alexey Dobriyan wrote: Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 10/33] netns ct: per-netns /proc/net/nf_conntrack_expect
Alexey Dobriyan wrote: Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/33] netns ct: per-netns /proc/net/ip_conntrack, /proc/net/stat/ip_conntrack, /proc/net/ip_conntrack_expect
Alexey Dobriyan wrote: Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 09/33] netns ct: per-netns /proc/net/nf_conntrack, /proc/net/stat/nf_conntrack
Alexey Dobriyan wrote: Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 08/33] netns ct: pass netns pointer to L4 protocol's ->error hook
Alexey Dobriyan wrote: > Again, it's deducible from skb, but we're going to use it for > nf_conntrack_checksum and statistics, so just pass it from upper layer. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 07/33] netns ct: pass netns pointer to nf_conntrack_in()
Alexey Dobriyan wrote: > It's deducible from skb->dev or skb->dst->dev, but we know netns at > the moment of call, so pass it down and use for finding and creating > conntracks. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 06/33] netns ct: per-netns unconfirmed list
Alexey Dobriyan wrote: > What is confirmed connection in one netns can very well be unconfirmed > in another one. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 05/33] netns ct: per-netns expectations
Alexey Dobriyan wrote:
> Make per-netns a) expectation hash and b) expectations count.
>
> Expectations always belongs to netns to which it's master conntrack belong.
> This is natural and doesn't bloat expectation.
>
> Proc files and leaf users are stubbed to init_net, this is temporary.
Looks fine, applied.
> @@ -406,7 +404,7 @@ int nf_ct_expect_related(struct nf_conntrack_expect
> *expect)
> }
> }
>
> - if (nf_ct_expect_count >= nf_ct_expect_max) {
> + if (net->ct.expect_count >= nf_ct_expect_max) {
> if (net_ratelimit())
> printk(KERN_WARNING
> "nf_conntrack: expectation table full\n");
I assume these message are globally visible even with namespaces?
Can we make this (and the corresponding ct hash message) refer to
the namespace? Otherwise it might be a bit confusing.
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 04/33] Fix {ip,6}_route_me_harder() in netns
Alexey Dobriyan wrote: > Take netns from skb->dst->dev. It should be safe because, they are called > from LOCAL_OUT hook where dst is valid (though, I'm not exactly sure about > IPVS and queueing packets to userspace). Its safe in all cases since they already expect to only get called when skb->dst is valid. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 03/33] nf_conntrack_gre: nf_ct_gre_keymap_flush() fixlet
Alexey Dobriyan wrote: > It does "kfree(list_head)" which looks wrong because entity that was > allocated is definitely not list_head. > > However, this all works because list_head is first item in > struct nf_ct_gre_keymap . The first three patches are already in Linus' tree. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 20/38] netns ct: NOTRACK in netns
Jan Engelhardt wrote: > On Friday 2008-09-05 08:25, Patrick McHardy wrote: >>>> I hope so :) A different possiblity suggest by Pablo some time ago >>>> would be to mark untracked packets in skb->nfctinfo and not >>>> attach a conntrack at all. >>> Indeed, I remember that :). I left that patch of the table time ago [1]. >>> There's a nf_reset call missing as Patrick said at that time. I can >>> recover it if you like the idea. >> I think that would be a good idea. > > Would that work? Right now, a ct==NULL indicates the 'INVALID' state, > and overloading it with 'UNTRACKED' does not seem nice. ct == NULL would indicate either untracked or invalid. For the cases where it makes a difference, ctinfo has to be checked additionally. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 20/38] netns ct: NOTRACK in netns
Pablo Neira Ayuso wrote: > Patrick McHardy wrote: >>>> I think you could avoid this mess by using a struct nf_conntrack >>>> for the untracked conntrack instead of struct nf_conn. It shouldn't >>>> make any difference since its ignored anyways. >>> Ewww, can I? >> I hope so :) A different possiblity suggest by Pablo some time ago >> would be to mark untracked packets in skb->nfctinfo and not >> attach a conntrack at all. > > Indeed, I remember that :). I left that patch of the table time ago [1]. > There's a nf_reset call missing as Patrick said at that time. I can > recover it if you like the idea. I think that would be a good idea. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 20/38] netns ct: NOTRACK in netns
Alexey Dobriyan wrote: > On Thu, Sep 04, 2008 at 06:54:16PM +0200, Patrick McHardy wrote: >> [EMAIL PROTECTED] wrote: >>> Make untracked conntrack per-netns. Compare conntracks with relevant >>> untracked one. >>> >>> The following code you'll start laughing at this code: >>> >>> if (ct == ct->ct_net->ct.untracked) >>> ... >>> >>> let me remind you that ->ct_net is set in only one place, and never >>> overwritten later. >>> >>> All of this requires some surgery with headers, otherwise horrible circular >>> dependencies. And we lost nf_ct_is_untracked() as function, it became macro. >> I think you could avoid this mess by using a struct nf_conntrack >> for the untracked conntrack instead of struct nf_conn. It shouldn't >> make any difference since its ignored anyways. > > Ewww, can I? I hope so :) A different possiblity suggest by Pablo some time ago would be to mark untracked packets in skb->nfctinfo and not attach a conntrack at all. > Regardless of netns, switching to > > struct nf_conntrack nf_conntrack_untracked; > > means we must be absolutely sure that every place which uses, say, > ct->status won't get untracked conntrack. > > For example, does setting IPS_NAT_DONE_MASK and IPS_CONFIRMED_BIT on > untracked conntracked really necessary? I don't think so, untracked conntracks are skipped early in the NAT table. > In conntrack_mt_v0() "ct->status" can be used even for untracked connection, > is this right? It looks that way, but its not right. I think it should return false for every match except on (untracked) state. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 21/25] netns ct: per-netns event cache
Alexey Dobriyan wrote:
> On Thu, Sep 04, 2008 at 06:58:38PM +0200, Patrick McHardy wrote:
>> [EMAIL PROTECTED] wrote:
>>> static inline void
>>> -nf_conntrack_event_cache(enum ip_conntrack_events event,
>>> +nf_conntrack_event_cache(struct net *net, enum ip_conntrack_events event,
>>> const struct sk_buff *skb)
>>> {
>> Passing the conntrack instead of the struct net and the skb
>> would probably keep the callers cleaner.
>
> Dunno, passing netns explicitly like saying conntrack event happened in
> netns A, which is reasonable. OTOH, s/skb/ct/ is indeed nicer.
>
> I'll change it as you suggest and see what happens.
>
> BTW, I asked earlier if untracked conntracks are ever supposed to drop into
> event cache. If they're, trimming nf_conntrack_untracked is out of question.
No, they are skipped by the only event handler, ctnetlink.
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 25/38] netns ct: honest net.netfilter.nf_conntrack_count
[EMAIL PROTECTED] wrote: > Note, sysctl table is always duplicated, this is simpler, less special-cased, > less mistakes (and did one mistake in first version of this patch). This also doesn't explain what the patch is doing at all. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 21/25] netns ct: per-netns event cache
[EMAIL PROTECTED] wrote:
> static inline void
> -nf_conntrack_event_cache(enum ip_conntrack_events event,
> +nf_conntrack_event_cache(struct net *net, enum ip_conntrack_events event,
>const struct sk_buff *skb)
> {
Passing the conntrack instead of the struct net and the skb
would probably keep the callers cleaner.
> struct nf_conn *ct = (struct nf_conn *)skb->nfct;
> struct nf_conntrack_ecache *ecache;
>
> local_bh_disable();
> - ecache = &__get_cpu_var(nf_conntrack_ecache);
> + ecache = per_cpu_ptr(net->ct.ecache, raw_smp_processor_id());
> if (ct != ecache->ct)
> __nf_ct_event_cache_init(ct);
> ecache->events |= event;
> @@ -60,16 +58,29 @@ nf_ct_expect_event(enum ip_conntrack_expect_events event,
> atomic_notifier_call_chain(&nf_ct_expect_chain, event, exp);
> }
>
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 24/38] netns ct: per-netns statistics in proc
[EMAIL PROTECTED] wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Changelog please, I was wondering whether this was a resend of the last one. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 20/38] netns ct: NOTRACK in netns
[EMAIL PROTECTED] wrote:
> Make untracked conntrack per-netns. Compare conntracks with relevant
> untracked one.
>
> The following code you'll start laughing at this code:
>
> if (ct == ct->ct_net->ct.untracked)
> ...
>
> let me remind you that ->ct_net is set in only one place, and never
> overwritten later.
>
> All of this requires some surgery with headers, otherwise horrible circular
> dependencies. And we lost nf_ct_is_untracked() as function, it became macro.
I think you could avoid this mess by using a struct nf_conntrack
for the untracked conntrack instead of struct nf_conn. It shouldn't
make any difference since its ignored anyways.
>
> struct netns_ct {
> atomic_tcount;
> @@ -12,5 +13,7 @@ struct netns_ct {
> struct hlist_head *expect_hash;
> int expect_vmalloc;
> struct hlist_head unconfirmed;
> + /* Fake conntrack entry for untracked connections */
> + struct nf_conn untracked;
> };
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 10/38] netns ct: per-netns expectations
[EMAIL PROTECTED] wrote: > Make per-netns expectation hash and expectation count. > > Expectation always belongs to netns to which it's master conntrack belongs. > This is natural and allows to not bloat expectations. > > Proc files and leaf users in protocol modules are stubbed to init_net, > this is temporary. This one again introduces overly long lines, please fix up the remaining patches yourself and resend. I'll upload my current tree to kernel.org so you can use it as a base (will take a couple of minutes): git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 11/38] netns ct: per-netns unconfirmed hash
[EMAIL PROTECTED] wrote:
> What is unconfirmed connection in one netns can very well be confirmed
> in another.
>
> @@ -10,5 +11,6 @@ struct netns_ct {
> unsigned intexpect_count;
> struct hlist_head *expect_hash;
> int expect_vmalloc;
> + struct hlist_head unconfirmed;
> };
You could lay this out a bit better to avoid holes and move
the members only used rarely (like *_vmalloc) to the end.
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 09/38] netns ct: per-netns conntrack hash
[EMAIL PROTECTED] wrote: > * make per-netns conntrack hash > > Other solution is to add ->ct_net pointer to tuplehashes and still has one > hash, I tried that it's ugly and requires more code deep down in protocol > modules et al. > > * propagate netns pointer to where needed, e. g. to conntrack iterators. Applied with more overly long line fixes. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 08/38] netns ct: per-netns conntrack count
[EMAIL PROTECTED] wrote: > Sysctls and proc files are stubbed to init_net's one. This is temporary. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 07/38] netns ct: add ->ct_net -- pointer from conntrack to netns
[EMAIL PROTECTED] wrote: > Conntrack (struct nf_conn) gets pointer to netns: ->ct_net -- netns in which > it was created. It comes from netdevice. > > ->ct_net is write-once field. > > Every conntrack in system has ->ct_net initialized, no exceptions. > > ->ct_net doesn't pin netns: conntracks are recycled after timeouts and > pinning background traffic will prevent netns from even starting shutdown > sequence. > > Right now every conntrack is created in init_net. Applied and fixed up another overly long line. > + h = init_conntrack(&init_net, &tuple, l3proto, l4proto, skb, > dataoff); This will probably cause clashes later, please don't do that. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 05/38] Fix ip{,6}_route_me_harder() in netns
[EMAIL PROTECTED] wrote: > ip_route_me_harder() is called on output codepaths: > 1) IPVS: honestly, not sure, looks like it can be called during forwarding > 2) IPv4 REJECT: refreshing comment re skb->dst is valid and assigment of >skb->dst right before call :^) > 3) NAT: called in LOCAL_OUT hook > 4) iptable_mangle: LOCAL_OUT hook > 5) nf_ip_reroute(): LOCAL_OUT hook (no clue about queueing packets to > luserspace) > > ip6_route_me_harder() is also called in output codepaths: > 1) ip6table_mangle: LOCAL_OUT hook > 2) nf_ip6_reroute: LOCAL_OUT hook (ditto) This changelog doesn't give much clue what the patch is doing or even what the problem is. It also doesn't seem that you're very convinced of its correctness. Please resend with a proper changelog. If you have any questions about the contexts in which this function is called, just ask. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 06/37] netns ct: add netns boilerplate
[EMAIL PROTECTED] wrote: > One comment: #ifdefs around #include is necessary to overcome amazing compile > breakages in NOTRACK-in-netns patch (see below). I guess thats because of the net/netfilter/nf_conntrack.h inclusion. We should fix that, its spreading to too many places. Anyways, applied. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 03/38] netns nf: ip6table_mangle in netns for real
[EMAIL PROTECTED] wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Applied, thanks. > @@ -108,7 +120,7 @@ ip6t_local_hook(unsigned int hook, > /* flowlabel and prio (includes version, which shouldn't change either > */ > flowlabel = *((u_int32_t *)ipv6_hdr(skb)); > > - ret = ip6t_do_table(skb, hook, in, out, init_net.ipv6.ip6table_mangle); > + ret = ip6t_do_table(skb, hook, in, out, > dev_net(out)->ipv6.ip6table_mangle); I've fixed this to stay under the 80 char limit. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 04/38] netns nf: ip6t_REJECT in netns for real
[EMAIL PROTECTED] wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 02/38] netns nf: ip6table_raw in netns for real
[EMAIL PROTECTED] wrote: > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 01/38] netns nf: remove nf_*_net() wrappers
[EMAIL PROTECTED] wrote: > Now that dev_net() exists, the usefullness of them is even less. Also they're > a big problem in resolving circular header dependencies necessary for > NOTRACK-in-netns patch. See below. Applied, thanks. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: unlock iptables in netns
Alexey Dobriyan wrote: On Mon, Jun 16, 2008 at 01:16:00PM +0200, Patrick McHardy wrote: Alexey Dobriyan wrote: On Mon, Jun 16, 2008 at 12:26:03PM +0200, Patrick McHardy wrote: By the way, is there already work done for conntrack/NAT namespace support? I have this patch that uses marks for something very similar that should be easy to adjust. Yes, right now I'm fighting something which looks like double free of conntrack during clone(CLONE_NEWNET)/exit test despite none created in netns. And unknown to me dimensions of input and output packet codepaths. :^) Preliminaty details: struct nf_conn::ct_net which pins netns Ouch, now that I have converted conntracking code, "pins netns" part is really stupid, just background traffic on network will prevent netns from destroying. Can't you do active cleanup instead of pinning the namespace? ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: unlock iptables in netns
Pavel Emelyanov wrote: Patrick McHardy wrote: Alexey Dobriyan wrote: On Mon, Jun 16, 2008 at 12:26:03PM +0200, Patrick McHardy wrote: By the way, is there already work done for conntrack/NAT namespace support? I have this patch that uses marks for something very similar that should be easy to adjust. Yes, right now I'm fighting something which looks like double free of conntrack during clone(CLONE_NEWNET)/exit test despite none created in netns. And unknown to me dimensions of input and output packet codepaths. :^) Preliminaty details: struct nf_conn::ct_net which pins netns From the VLAN code, I thought namespaces could also be identified numerically. That would reduce the size increase of struct nf_conn. Numerically? I made VLAN-s netnsization, but everything was spinning around the struct net *pointer*. Can you elaborate on this? I think I just misunderstood the meaning of vlan_net_id. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: unlock iptables in netns
Alexey Dobriyan wrote: On Mon, Jun 16, 2008 at 12:26:03PM +0200, Patrick McHardy wrote: By the way, is there already work done for conntrack/NAT namespace support? I have this patch that uses marks for something very similar that should be easy to adjust. Yes, right now I'm fighting something which looks like double free of conntrack during clone(CLONE_NEWNET)/exit test despite none created in netns. And unknown to me dimensions of input and output packet codepaths. :^) Preliminaty details: struct nf_conn::ct_net which pins netns From the VLAN code, I thought namespaces could also be identified numerically. That would reduce the size increase of struct nf_conn. netns of expectation is netns of master conntrack by definition per-netns conntrack hash per-netns expect hash per-netns unconfirmed list That all makes sense. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: unlock iptables in netns
Patrick McHardy wrote:
Alexey Dobriyan wrote:
Hi,
Den basically banned iptables in netns via this patch
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
...
, however, at least some of netfilter pieces are ready for usage in netns
and it would be nice to unlock them before release.
If I'm deciphering chengelog correctly it's all about code which does
nf_register_hook{,s} but not netns-ready itself:
br_netfilter.c
iptable_mangle (via ip_route_me_harder)
conntracking (both IPv4 and IPv6)
NAT
...
Patch above can be applied and we can mark above list as "depends
!NET_NS"
and move on.
Comments? Den, was there something else you're afraid of?
That might result in some bad surprises for people how have already
turned on NET_NS. I'd prefer a way that doesn't potentially disable
half the netfilter options in existing configs.
By the way, is there already work done for conntrack/NAT namespace
support? I have this patch that uses marks for something very similar
that should be easy to adjust.
diff --git a/include/net/netfilter/nf_conntrack_tuple.h
b/include/net/netfilter/nf_conntrack_tuple.h
index e69ab2e..49c4d0c 100644
--- a/include/net/netfilter/nf_conntrack_tuple.h
+++ b/include/net/netfilter/nf_conntrack_tuple.h
@@ -91,6 +91,8 @@ struct nf_conntrack_tuple
/* The direction (for tuplehash) */
u_int8_t dir;
} dst;
+
+ u_int32_t mark;
};
struct nf_conntrack_tuple_mask
@@ -140,7 +142,8 @@ static inline int __nf_ct_tuple_src_equal(const struct
nf_conntrack_tuple *t1,
t1->src.u3.all[2] == t2->src.u3.all[2] &&
t1->src.u3.all[3] == t2->src.u3.all[3] &&
t1->src.u.all == t2->src.u.all &&
- t1->src.l3num == t2->src.l3num);
+ t1->src.l3num == t2->src.l3num &&
+ t1->mark == t2->mark);
}
static inline int __nf_ct_tuple_dst_equal(const struct nf_conntrack_tuple *t1,
@@ -151,7 +154,8 @@ static inline int __nf_ct_tuple_dst_equal(const struct
nf_conntrack_tuple *t1,
t1->dst.u3.all[2] == t2->dst.u3.all[2] &&
t1->dst.u3.all[3] == t2->dst.u3.all[3] &&
t1->dst.u.all == t2->dst.u.all &&
- t1->dst.protonum == t2->dst.protonum);
+ t1->dst.protonum == t2->dst.protonum &&
+ t1->mark == t2->mark);
}
static inline int nf_ct_tuple_equal(const struct nf_conntrack_tuple *t1,
@@ -187,7 +191,8 @@ static inline int nf_ct_tuple_src_mask_cmp(const struct
nf_conntrack_tuple *t1,
return 0;
if (t1->src.l3num != t2->src.l3num ||
- t1->dst.protonum != t2->dst.protonum)
+ t1->dst.protonum != t2->dst.protonum ||
+ t1->mark != t2->mark)
return 0;
return 1;
diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
index a65b845..7b50593 100644
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -52,9 +52,10 @@ static int ipv4_invert_tuple(struct nf_conntrack_tuple
*tuple,
static int ipv4_print_tuple(struct seq_file *s,
const struct nf_conntrack_tuple *tuple)
{
- return seq_printf(s, "src=%u.%u.%u.%u dst=%u.%u.%u.%u ",
+ return seq_printf(s, "src=%u.%u.%u.%u dst=%u.%u.%u.%u mark=%u ",
NIPQUAD(tuple->src.u3.ip),
- NIPQUAD(tuple->dst.u3.ip));
+ NIPQUAD(tuple->dst.u3.ip),
+ tuple->mark);
}
/* Returns new sk_buff, or NULL */
diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c
index 36b4e3b..a2e76dc 100644
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -82,7 +82,7 @@ hash_by_src(const struct nf_conntrack_tuple *tuple)
/* Original src, to ensure we map it consistently if poss. */
hash = jhash_3words((__force u32)tuple->src.u3.ip,
(__force u32)tuple->src.u.all,
- tuple->dst.protonum, 0);
+ tuple->dst.protonum ^ tuple->mark, 0);
return ((u64)hash * nf_nat_htable_size) >> 32;
}
@@ -140,7 +140,8 @@ same_src(const struct nf_conn *ct,
t = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
return (t->dst.protonum == tuple->dst.protonum &&
t->src.u3.ip == tuple->src.u3.ip &&
- t->src.u.all == tuple->src.u.all);
+ t->src.u.all == tuple->src.u.all &&
+ t->mark == tuple->mark);
}
/* Only called for SRC manip */
@@ -213,7 +
[Devel] Re: unlock iptables in netns
Alexey Dobriyan wrote:
Hi,
Den basically banned iptables in netns via this patch
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
...
, however, at least some of netfilter pieces are ready for usage in netns
and it would be nice to unlock them before release.
If I'm deciphering chengelog correctly it's all about code which does
nf_register_hook{,s} but not netns-ready itself:
br_netfilter.c
iptable_mangle (via ip_route_me_harder)
conntracking (both IPv4 and IPv6)
NAT
arptable_filter
selinux
decnet
ebtable_filter
ebtable_nat
ipt_CLUSTERIP
Patch above can be applied and we can mark above list as "depends !NET_NS"
and move on.
Comments? Den, was there something else you're afraid of?
That might result in some bad surprises for people how have already
turned on NET_NS. I'd prefer a way that doesn't potentially disable
half the netfilter options in existing configs.
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH] nf_conntrack: fix error path unwind in nf_conntrack_expect_init()
Alexey Dobriyan wrote: Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> --- net/netfilter/nf_conntrack_expect.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks Alexey. I'll also push this to -stable. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 6/14][RTNL]: Introduce the rtnl_kill_links call.
Pavel Emelyanov wrote:
>>> for_each_net(net) {
>>> -restart:
>>> - for_each_netdev_safe(net, dev, n) {
>>> - if (dev->rtnl_link_ops == ops) {
>>> - ops->dellink(dev);
>>> - goto restart;
>>> - }
>>> - }
>>> + __rtnl_kill_links(net, ops);
>> This was _safe, and now it's not. Is that intentional?
>
> Yup - we goto restart in case we del some link, so there's no need
> in _safe iteration.
>
> This goto was added by Partick (commit 68365458 [NET]: rtnl_link:
> fix use-after-free) and I suspect he simply forgot to remove the
> _safe iterator (I put him in Cc to correct me if I'm wrong).
No, that was an oversight, it should be safe to remove.
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH][VLAN]: Fix egress priority mappings leak.
Pavel Emelyanov wrote: These entries are allocated in vlan_dev_set_egress_priority, but are never released and leaks on vlan device removal. Drop these in vlan's ->uninit callback - after the device is brought down and everyone is notified about it is going to be unregistered. Found during testing vlan netnsization patchset. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Good catch, thanks. Acked-by: Patrick McHardy <[EMAIL PROTECTED]> ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH][VLAN]: Proc entry is not renamed when vlan device name changes.
Pavel Emelyanov wrote: This may lead to situations, when each of two proc entries produce data for the other's device. Looks like a BUG, so this patch is for net-2.6. It will not apply to net-2.6.26 since dev->nd_net access is replaced with dev_net(dev) one. Should I rework the patch to fit 2.6.26? No, since its a bugfix it should go in net-2.6. Dave, please apply. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH] NETFILTER: per-netns FILTER/MANGLE/RAW tables for real
Alexey Dobriyan wrote: Commit 9335f047fe61587ec82ff12fbb1220bcfdd32006 aka "[NETFILTER]: ip_tables: per-netns FILTER, MANGLE, RAW" added per-netns _view_ of iptables rules. They were shown to user, but ignored by filtering code. Now that it's possible to at least ping loopback, per-netns tables can affect filtering decisions. netns is taken in case of PRE_ROUTING, LOCAL_IN -- from in device, POST_ROUTING, LOCAL_OUT -- from out device, FORWARD -- from in device which should be equal to out device's netns. This code is relatively new, so BUG_ON was plugged. Wrappers were added to a) keep code the same from CONFIG_NET_NS=n users (overwhelming majority), b) consolidate code in one place -- similar changes will be done in ipv6 and arp netfilter code. Applied, thanks. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH] Don't limit the number of tunnels with generic name explicitly.
Pavel Emelyanov wrote: Patrick McHardy wrote: Pavel Emelyanov wrote: Patrick McHardy wrote: It would be nicer to replace the entire hand-made name allocation to remove the 100 device limit. Actually, I thought the same, but fixing % in names looks like a BUG-fix for 2.6.25, while removing the hand-made name allocation looks like an enhancement for 2.6.26. No? Well, its so closely related that I guess it would still look like a bugfix :) But changing this in 2.6.26 is also fine of course, your patch just reminded me since I wanted to change this for a long time and repeatedly forgot about it again. Ok, point taken ;) Here's the 2nd patch that does so. If David decides it can go to 2.6.25, that would be good, otherwise this patch will fit the 2.6.26 as well. Changelog: Use the added dev_alloc_name() call to create tunnel device name, rather than iterate in a hand-made loop with an artificial limit. Thanks Patrick for noticing this. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Looks good to me, thanks. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH] Don't create tunnels with '%' in name.
Pavel Emelyanov wrote: Patrick McHardy wrote: It would be nicer to replace the entire hand-made name allocation to remove the 100 device limit. Actually, I thought the same, but fixing % in names looks like a BUG-fix for 2.6.25, while removing the hand-made name allocation looks like an enhancement for 2.6.26. No? Well, its so closely related that I guess it would still look like a bugfix :) But changing this in 2.6.26 is also fine of course, your patch just reminded me since I wanted to change this for a long time and repeatedly forgot about it again. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH] Don't create tunnels with '%' in name.
Pavel Emelyanov wrote:
Four tunnel drivers (ip_gre, ipip, ip6_tunnel and sit) can
receive a pre-defined name for a device from the userspace.
Since these drivers call the register_netdevice() after this
(rtnl_lock is held), the device's name may contain a '%'
character.
Not sure how bad is this to have a device with a '%' in its
name, but all the other places either use the register_netdev(),
or explicitly call dev_alloc_name() before registering, i.e.
do not allow for such names.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 63f6917..6b9744f 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -274,19 +274,24 @@ static struct ip_tunnel * ipgre_tunnel_locate(struct
ip_tunnel_parm *parms, int
if (!dev)
return NULL;
+ if (strchr(name, '%')) {
+ if (dev_alloc_name(dev, name) < 0)
+ goto failed_free;
+ }
+
It would be nicer to replace the entire hand-made name
allocation to remove the 100 device limit.
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 3/17 net-2.6.26] [NETFILTER]: Consolidate masq_inet_event and masq_device_event.
Denis V. Lunev wrote: They do exactly the same job. Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]> --- net/ipv4/netfilter/ipt_MASQUERADE.c | 14 ++ 1 files changed, 2 insertions(+), 12 deletions(-) Looks fine. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 2/3] netns netfilter: netns propagation for /proc/net/*_tables_names
Alexey Dobriyan wrote: Propagate netns together with AF down to ->start/->next/->stop iterators. Choose table based on netns and AF for showing. Applied. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 3/3] netns netfilter: create per-netns /proc/net/*_tables_*
Alexey Dobriyan wrote: Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> --- include/linux/netfilter/x_tables.h |4 ++-- net/ipv4/netfilter/arp_tables.c| 21 ++--- net/ipv4/netfilter/ip_tables.c | 21 ++--- net/ipv6/netfilter/ip6_tables.c| 22 +++--- net/netfilter/x_tables.c | 20 ++-- 5 files changed, 67 insertions(+), 21 deletions(-) Also applied, thanks. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] netns netfilter: semi-rewrite of /proc/net/foo_tables_*
Alexey Dobriyan wrote: Argh, there are many small but still wrong things with /proc/net/*_tables_* so I decided to do overhaul simultaneously making it more suitable for per-netns /proc/net/*_tables_* implementation. Fix a) xt_get_idx() duplicating now standard seq_list_start/seq_list_next iterators b) tables/matches/targets list was chosen again and again on every ->next c) multiple useless "af >= NPROTO" checks -- we simple don't supply invalid AFs there and registration function should BUG_ON instead. Regardless, the one in ->next() is the most useless -- ->next doesn't run at all if ->start fails. d) Don't use mutex_lock_interruptible() -- it can fail and ->stop is executed even if ->start failed, so unlock without lock is possible. As side effect, streamline code by splitting xt_tgt_ops into xt_target_ops, xt_matches_ops, xt_tables_ops. xt_tables_ops hooks will be changed by per-netns code. Code of xt_matches_ops, xt_target_ops is identical except the list chosen for iterating, but I think consolidating code for two files not worth it given "<< 16" hacks needed for it. Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Applied, and I also removed the now unused TABLE/TARGET/MATCH enum. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 5/5] netns netfilter: put table module on netns stop
Alexey Dobriyan wrote: When number of entries exceeds number of initial entries, foo-tables code will pin table module. But during table unregister on netns stop, that additional pin was forgotten. Applied, thanks. ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
