[Devel] Re: Revert for cgroups CPU accounting subsystem patch

2007-11-13 Thread Paul Menage
On Nov 12, 2007 11:59 PM, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:

 Thinking of it more, this requirement to group tasks for only accounting
 purpose may be required for other resources (mem, io, network etc) as well?
 Should we have a generic accounting controller which can provide these
 various resource usgae stats for a group (cpu, mem etc) by iterating thr' the
 task list for the group and summing up the corresponding stats already present
 in task structure?

In theory it could certainly be useful - but it can only be done if
something in the kernel is already keeping track of resources on a
per-task basis. This works for CPU, but isn't really possible for
memory without doing something lame like just adding up the tasks' RSS
values (since the page accounting is the hard part - limiting is easy
once you have accounting).

Paul
___
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/1][NETNS][IPV6] protect addrconf from loopback registration

2007-11-13 Thread Daniel Lezcano

Eric W. Biederman wrote:

Daniel Lezcano [EMAIL PROTECTED] writes:


Eric W. Biederman wrote:

Denis V. Lunev [EMAIL PROTECTED] writes:


Index: linux-2.6-netns/net/ipv6/addrconf.c
===
--- linux-2.6-netns.orig/net/ipv6/addrconf.c
+++ linux-2.6-netns/net/ipv6/addrconf.c
@@ -2272,7 +2272,8 @@ static int addrconf_notify(struct notifi
switch(event) {
case NETDEV_REGISTER:
-   if (!idev  dev-mtu = IPV6_MIN_MTU) {
+   if (!(dev-flags  IFF_LOOPBACK) 
+   !idev  dev-mtu = IPV6_MIN_MTU) {

It is idev being true here for the loopback device that would
prevent things not missing the REGISTER event.

Hmm.  But we do call ipv6_add_dev on loopback and now the loopback
device is practically guaranteed to be the first device so we can
probably just remove the special case in addrconf_init.

Anyway Daniels patch makes increasingly less sense the more I look
at it.

Let me try to clarify:

 * when the init network namespace is created, the loopback is created first,
before ipv6, and the notifier call chain for ipv6 is not setup, so the protocol
does not receive the REGISTER event

 * when the init network namespace is destroyed during shutdown, the loopback is
not unregistered, so there is no UNREGISTER event


* When addrconf_init calls register_netdevice_notifier we receive
  NETDEV_REGISTER and NETDEV_UP for all network devices that are in
  the system including the loopback device.


Thanks for the information. Effectively, I missed this :|


 * when we create a new network namespace, a new instance of the loopback is
created and a NETDEV_REGISTER is sent to ipv6 because the notifier call chain
has been setup by the init netns (while ipv6 protocol is not yet configured for
the namespace which is being created)


Possibly there may be some ordering issues here.


 * when the network namespace exits, the loopback is unregistered after the ipv6
protocol but the NETDEV_UNREGISTER is sent to addrconf_notify while the ipv6
protocol has been destroyed.


The objective of the patch is to discard these events because they were never
taken into account and they are not expected to be receive by ipv6 protocol.


My opinion is that both your analysis is slightly off (as to the cause
of your problems) and that your approach to fix your problem is wrong
because you don't untangle the knot you keep it.


Yes, I will look at how to fix that properly.


...
I have register_pernet_subsys and register_per_net_device to ensure
that when we create a new network namespace all of the subsystems are
initialized before the network devices are initialize.  So ipv6 should
be ready before we initialize the new loopback device comes into
existence.

The preservation of the order of the network namespace callbacks
ensures that the loopback device will be the first network device
registered, and if it helps we can take advantage of that in reference
to the weirdness from the comment below.

/* The addrconf netdev notifier requires that loopback_dev
 * has it's ipv6 private information allocated and setup
 * before it can bring up and give link-local addresses
 * to other devices which are up.
 *
 * Unfortunately, loopback_dev is not necessarily the first
 * entry in the global dev_base list of net devices.  In fact,
 * it is likely to be the very last entry on that list.
 * So this causes the notifier registry below to try and
 * give link-local addresses to all devices besides loopback_dev
 * first, then loopback_dev, which cases all the non-loopback_dev
 * devices to fail to get a link-local address.
 *
 * So, as a temporary fix, allocate the ipv6 structure for
 * loopback_dev first by hand.
 * Longer term, all of the dependencies ipv6 has upon the loopback
 * device and it being up should be removed.
 */

We can just special case registration of the loopback device to
do:
ip6_null_entry.u.dst.dev = init_net.loopback_dev;
ip6_null_entry.rt6i_idev = in6_dev_get(init_net.loopback_dev);
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
ip6_prohibit_entry.u.dst.dev = init_net.loopback_dev;
ip6_prohibit_entry.rt6i_idev = in6_dev_get(init_net.loopback_dev);
ip6_blk_hole_entry.u.dst.dev = init_net.loopback_dev;
ip6_blk_hole_entry.rt6i_idev = in6_dev_get(init_net.loopback_dev);
#endif

Which would remove the special case from addrconf_init.



___
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/2] cleanup pernet operation without CONFIG_NET_NS

2007-11-13 Thread David Miller
From: Denis V. Lunev [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 15:00:07 +0300

 If CONFIG_NET_NS is not set, the only namespace is possible.
 
 This patch removes list of pernet_operations and cleanups code a bit.
 This list is not needed if there are no namespaces. We should just call
 -init method.
 
 Additionally, the -exit will be called on module unloading only. This
 case is safe - the code is not discarded. For the in/kernel code, -exit
 should never be called.
 
 Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]

Applied.

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel


[Devel] Re: [PATCH 2/2] move unneeded data to initdata section

2007-11-13 Thread David Miller
From: Denis V. Lunev [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 15:01:00 +0300

 This patch reverts Eric's commit 2b008b0a8e96b726c603c5e1a5a7a509b5f61e35
 
 It diets .text  .data section of the kernel if CONFIG_NET_NS is not set.
 This is safe after list operations cleanup.
 
 Signed-of-by: Denis V. Lunev [EMAIL PROTECTED]

Applied, thanks Denis.

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel


[Devel] [PATCH] [NETFILTER] ipt_SAME: add compat conversion functions

2007-11-13 Thread Konstantin Khorenko
[NETFILTER]: ipt_SAME: add compat conversion functions

ipt_SAME should have the compat function cause its entry structure 
(ipt_same_info)
contains a pointer between data filled/checked in both kernel and userspace.

Signed-off-by: Konstantin Khorenko [EMAIL PROTECTED]

---
Thank you,
Konstantin Khorenko

SWsoft Virtuozzo/OpenVZ Linux kernel team

--- ./net/ipv4/netfilter/ipt_SAME.c.SAME2007-11-06 13:55:16.0 
+0300
+++ ./net/ipv4/netfilter/ipt_SAME.c 2007-11-09 16:50:38.0 +0300
@@ -152,6 +152,47 @@ same_target(struct sk_buff *skb,
return nf_nat_setup_info(ct, newrange, hooknum);
 }
 
+#ifdef CONFIG_COMPAT
+struct compat_ipt_same_info
+{
+   unsigned char info;
+   u_int32_t rangesize;
+   u_int32_t ipnum;
+   compat_uptr_t iparray;
+
+   /* hangs off end. */
+   struct nf_nat_range range[IPT_SAME_MAX_RANGE];
+};
+
+static void compat_from_user(void *dst, void *src)
+{
+   const struct compat_ipt_same_info *cl = src;
+   struct ipt_same_info l = {
+   .info   = cl-info,
+   .rangesize  = cl-rangesize,
+   .ipnum  = 0,
+   .iparray= NULL,
+   };
+
+   memcpy(l.range, cl-range, sizeof(l.range));
+   memcpy(dst, l, sizeof(l));
+}
+
+static int compat_to_user(void __user *dst, void *src)
+{
+   const struct ipt_same_info *l = src;
+   struct compat_ipt_same_info cl = {
+   .info   = l-info,
+   .rangesize  = l-rangesize,
+   .ipnum  = 0,
+   .iparray= (compat_uptr_t)NULL,
+   };
+
+   memcpy(cl.range, l-range, sizeof(cl.range));
+   return copy_to_user(dst, cl, sizeof(cl)) ? -EFAULT : 0;
+}
+#endif /* CONFIG_COMPAT */
+
 static struct xt_target same_reg __read_mostly = {
.name   = SAME,
.family = AF_INET,
@@ -161,6 +202,11 @@ static struct xt_target same_reg __read_
.hooks  = (1  NF_IP_PRE_ROUTING | 1  NF_IP_POST_ROUTING),
.checkentry = same_check,
.destroy= same_destroy,
+#ifdef CONFIG_COMPAT
+   .compatsize = sizeof(struct compat_ipt_same_info),
+   .compat_from_user = compat_from_user,
+   .compat_to_user = compat_to_user,
+#endif
.me = THIS_MODULE,
 };
 

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel


[Devel] [NETFILTER]: Unable to delete a SAME rule (Using SAME target problems)

2007-11-13 Thread Konstantin Khorenko
Dear all,

The problem description: unable to delete a SAME target rule.

The problem has been already raised some time ago - at least here:
http://marc.info/?l=netfilterm=117246219803862w=2

The problem was originally found using 2.6.18-8.1.15.el5 x86_64 kernel and
iptables v1.3.5 (stock RHEL5) but it seems to me that the problem is still not
fixed in newer kernel/iptables versions.

---
[EMAIL PROTECTED] ~]# iptables -N foo -t nat
[EMAIL PROTECTED] ~]# iptables -t nat -A foo -j SAME --to 1.2.3.4
[EMAIL PROTECTED] ~]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain foo (0 references)
target prot opt source   destination
SAME   all  --  anywhere anywheresame:1.2.3.4
[EMAIL PROTECTED] ~]# iptables -t nat -D foo -j SAME --to 1.2.3.4
iptables: No chain/target/match by that name
---


The root of the problem - the structure ipt_same_info:
struct ipt_same_info
{
unsigned char info;
u_int32_t rangesize;
u_int32_t ipnum;
u_int32_t *iparray;

/* hangs off end. */
struct ip_nat_range range[IPT_SAME_MAX_RANGE];
};

ipnum  iparray is filled/used in kernel space only.

Userspace (iptables) tries to delete the rule:
1) it asks the kernel for the existing table

2) kernel provides the table.
Note: due to generic copy code 'ipt_same_info' structure is completely filled
up like any other entry structure, i mean - 'ipnum' and 'iparray' are non-zero!

3) iptables generates the ipt_same_info structure for the rule which it tries
to delete.
ipnum and iparray are zeroed.

4) iptables searches the table provided by kernel for the rule to be deleted.
It compares many things and at the end it compares the module dependent
structures (ipt_same_info).
Ok, iptables also uses the generic code for comparison module dependent
structures, so it tries not to compare the complete structure, but only first
(struct iptables_target).userspacesize bytes of it.

extensions/libipt_SAME.c:
...
static struct iptables_target same_target = {
.name   = SAME,
.version= IPTABLES_VERSION,
.size   = IPT_ALIGN(sizeof(struct ipt_same_info)),
.userspacesize  = IPT_ALIGN(sizeof(struct ipt_same_info)),
...

But it has to set '.userspacesize' to sizeof(struct ipt_same_info) because it
must compare the 'range' array of the 'ipt_same_info' cause it contains range
descriptions.

5) Trying to compare complete 'ipt_same_info' iptables is unable to find the
requested rule for deletion because 'ipnum' and 'iparray' fields always differ
(zero in userspace-generated structure and non-zero in the tables provided by
kernel).

6) So the deletion fails.


At the moment i can see only 3 ways of fixing this:
* reassemble struct ipt_same_info - put 'ipnum' and 'iparray' at the end of the
structure. This will save generic code both in kernel and userspace.

* let struct ipt_same_info be as is, teach userspace to manipulate more complex
masks (not only first X bytes of the structure)

* let struct ipt_same_info be as is, teach kernel to zero pointers and all the
fields which are used only in kernel.

All these ways are quite painful, but could someone please comment this - may
be i just missed and some decision had been already done on this issue?

---
Thank you,
Konstantin Khorenko

SWsoft Virtuozzo/OpenVZ Linux kernel team

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel


[Devel] Re: [patch 1/1][NETNS][IPV6] protect addrconf from loopback registration

2007-11-13 Thread Eric W. Biederman
David Miller [EMAIL PROTECTED] writes:

Well this is a weird way to get to this part of the conversation.

 From: Denis V. Lunev [EMAIL PROTECTED]
 Date: Mon, 12 Nov 2007 19:49:03 +0300

 Unregister for a loopback in !init_net is a _valid_ operation and should
 be clean, i.e. without kludges in the path. This is the only way to
 check the ref-counting.

 For ipv6 the stack really wants to pin down the loopback
 device because we need a valid inet6_dev object to reference
 at all times in order to simplify the per-device SNMP
 statistic bumping.

 When a non-loopback device goes down, we point any existing
 references to that device's idev to the loopback one instead.

 I really consider taking down the loopback device to be
 an invalid operation at least how things are implemented
 currently.

In a secondary network namespace the current implementation
registers the loopback device before all other network devices
in a network namespace and it unregisters the loopback device
after all other network devices.

So we don't endanger the current scheme of pointing any existing
reference to the loopback device.  In fact the current ipv6 addrconf_cleanup
largely does the same thing.

Unregistering the loopback device is definitely a case where we need
to tread very carefully.

Bug we absolutely need to do all of our cleanup for a network
namespace went it goes away and that includes removing the per network
namespace copy of the loopback device.

Eric
___
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] [PATCH][NET] Convert init_timer into setup_timer

2007-11-13 Thread Pavel Emelyanov
Many-many code in the kernel initialized the timer-function 
and  timer-data together with calling init_timer(timer). There 
is already a helper for this. Use it for networking code.

The patch is HUGE, but makes the code 130 lines shorter 
(98 insertions(+), 228 deletions(-)).

Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

---

 net/802/tr.c |4 +---
 net/appletalk/aarp.c |4 +---
 net/appletalk/ddp.c  |5 ++---
 net/atm/lec.c|5 ++---
 net/ax25/af_ax25.c   |5 ++---
 net/bluetooth/hci_conn.c |9 ++---
 net/bluetooth/hidp/core.c|5 +
 net/bluetooth/l2cap.c|   13 ++---
 net/bluetooth/rfcomm/core.c  |4 +---
 net/bluetooth/sco.c  |9 +
 net/core/flow.c  |3 +--
 net/core/neighbour.c |   12 +++-
 net/dccp/ccids/ccid2.c   |6 ++
 net/dccp/ccids/ccid3.c   |7 ++-
 net/dccp/timer.c |5 ++---
 net/decnet/dn_route.c|3 +--
 net/econet/af_econet.c   |3 +--
 net/ieee80211/ieee80211_module.c |5 ++---
 net/ipv4/igmp.c  |   14 +-
 net/ipv4/inet_connection_sock.c  |   17 +
 net/ipv4/inet_fragment.c |5 ++---
 net/ipv4/ipmr.c  |3 +--
 net/ipv4/ipvs/ip_vs_conn.c   |4 +---
 net/ipv4/ipvs/ip_vs_est.c|3 +--
 net/ipv4/ipvs/ip_vs_lblc.c   |5 ++---
 net/ipv4/ipvs/ip_vs_lblcr.c  |5 ++---
 net/ipv4/route.c |6 ++
 net/ipv6/addrconf.c  |4 +---
 net/ipv6/mcast.c |   14 +-
 net/irda/af_irda.c   |5 ++---
 net/iucv/af_iucv.c   |9 +
 net/llc/llc_conn.c   |   20 
 net/llc/llc_station.c|5 ++---
 net/mac80211/sta_info.c  |5 ++---
 net/netrom/nr_timer.c|   19 ---
 net/rose/af_rose.c   |5 ++---
 net/sched/sch_generic.c  |9 +
 net/sched/sch_sfq.c  |4 +---
 net/sctp/associola.c |8 +++-
 net/sctp/transport.c |   13 -
 net/sunrpc/sched.c   |5 ++---
 net/sunrpc/xprt.c|5 ++---
 net/tipc/core.h  |4 +---
 net/x25/x25_link.c   |5 +
 net/x25/x25_timer.c  |4 +---
 net/xfrm/xfrm_policy.c   |5 ++---
 net/xfrm/xfrm_state.c|9 +++--
 47 files changed, 98 insertions(+), 228 deletions(-)

diff --git a/net/802/tr.c b/net/802/tr.c
index a2bd0f2..d8a5386 100644
--- a/net/802/tr.c
+++ b/net/802/tr.c
@@ -641,10 +641,8 @@ struct net_device *alloc_trdev(int sizeof_priv)
 
 static int __init rif_init(void)
 {
-   init_timer(rif_timer);
rif_timer.expires  = sysctl_tr_rif_timeout;
-   rif_timer.data = 0L;
-   rif_timer.function = rif_check_expire;
+   setup_timer(rif_timer, rif_check_expire, 0);
add_timer(rif_timer);
 
proc_net_fops_create(init_net, tr_rif, S_IRUGO, rif_seq_fops);
diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index 6c5c6dc..b950fb6 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -874,9 +874,7 @@ void __init aarp_proto_init(void)
aarp_dl = register_snap_client(aarp_snap_id, aarp_rcv);
if (!aarp_dl)
printk(KERN_CRIT Unable to register AARP with SNAP.\n);
-   init_timer(aarp_timer);
-   aarp_timer.function = aarp_expire_timeout;
-   aarp_timer.data = 0;
+   setup_timer(aarp_timer, aarp_expire_timeout, 0);
aarp_timer.expires  = jiffies + sysctl_aarp_expiry_time;
add_timer(aarp_timer);
register_netdevice_notifier(aarp_notifier);
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index e0d37d6..3be55c8 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -177,10 +177,9 @@ static inline void atalk_destroy_socket(struct sock *sk)
 
if (atomic_read(sk-sk_wmem_alloc) ||
atomic_read(sk-sk_rmem_alloc)) {
-   init_timer(sk-sk_timer);
+   setup_timer(sk-sk_timer, atalk_destroy_timer,
+   (unsigned long)sk);
sk-sk_timer.expires= jiffies + SOCK_DESTROY_TIME;
-   sk-sk_timer.function   = atalk_destroy_timer;
-   sk-sk_timer.data   = (unsigned long)sk;
add_timer(sk-sk_timer);
} else
sock_put(sk);
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 7eb1b21..0a9c426 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -1789,9 +1789,8 @@ static struct lec_arp_table *make_entry(struct lec_priv 
*priv,
}
memcpy(to_return-mac_addr, mac_addr, ETH_ALEN);
INIT_HLIST_NODE(to_return-next);
-   init_timer(to_return-timer);
-   

[Devel] Re: [patch 1/1][NETNS][IPV6] protect addrconf from loopback registration

2007-11-13 Thread Eric W. Biederman
YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] writes:

 In article [EMAIL PROTECTED] (at Mon, 12 Nov 2007
 12:50:53 -0700), [EMAIL PROTECTED] (Eric W. Biederman) says:

 My opinion is that both your analysis is slightly off (as to the cause
 of your problems) and that your approach to fix your problem is wrong
 because you don't untangle the knot you keep it.
 :
 I have register_pernet_subsys and register_per_net_device to ensure
 that when we create a new network namespace all of the subsystems are
 initialized before the network devices are initialize.  So ipv6 should
 be ready before we initialize the new loopback device comes into
 existence.

 User may not load ipv6.ko at boot, and then do modprobe ipv6.
 Do you take this into account?

Absolutely.

In the general case the infrastructure has to work for netfilter, ipv6,
and other parts of the networking stack that can be made modular.

The only limitation is that if you update struct net to add a new field
to help a modular ipv6 the core kernel needs to be recompiled.

When you load ipv6.ko late in the game first we call the init methods
which will eventually register the per network namespace registration
methods.  Then register_netdevice_notifier is called.  At which point
ipv6 is ready for the registration method.

For additional network namespace (which is the case that was claimed
was in trouble) the pernet_susbsys logic initializes all of the
subsystems before it initializes any of the network devices.
Effectively persevering the initialization order that exists today
with just the init methods and register_netdevice_notifier.


Eric

___
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][NET] Convert init_timer into setup_timer

2007-11-13 Thread David Miller
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 16:10:03 +0300

 Many-many code in the kernel initialized the timer-function 
 and  timer-data together with calling init_timer(timer). There 
 is already a helper for this. Use it for networking code.
 
 The patch is HUGE, but makes the code 130 lines shorter 
 (98 insertions(+), 228 deletions(-)).
 
 Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

I have no objection to this patch, but it is 2.6.25
material for sure.

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel


[Devel] Re: [PATCH][NET] Convert init_timer into setup_timer

2007-11-13 Thread Arnaldo Carvalho de Melo
Em Tue, Nov 13, 2007 at 05:34:21AM -0800, David Miller escreveu:
 From: Pavel Emelyanov [EMAIL PROTECTED]
 Date: Tue, 13 Nov 2007 16:10:03 +0300
 
  Many-many code in the kernel initialized the timer-function 
  and  timer-data together with calling init_timer(timer). There 
  is already a helper for this. Use it for networking code.
  
  The patch is HUGE, but makes the code 130 lines shorter 
  (98 insertions(+), 228 deletions(-)).
  
  Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
 
 I have no objection to this patch, but it is 2.6.25
 material for sure.

Agreed, Pavel, if you want please stick:

Acked-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]

- Arnaldo

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel


[Devel] Re: [PATCH][NET] Convert init_timer into setup_timer

2007-11-13 Thread Pavel Emelyanov
Arnaldo Carvalho de Melo wrote:
 Em Tue, Nov 13, 2007 at 05:34:21AM -0800, David Miller escreveu:
 From: Pavel Emelyanov [EMAIL PROTECTED]
 Date: Tue, 13 Nov 2007 16:10:03 +0300

 Many-many code in the kernel initialized the timer-function 
 and  timer-data together with calling init_timer(timer). There 
 is already a helper for this. Use it for networking code.

 The patch is HUGE, but makes the code 130 lines shorter 
 (98 insertions(+), 228 deletions(-)).

 Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
 I have no objection to this patch, but it is 2.6.25
 material for sure.

OK.

 Agreed, Pavel, if you want please stick:
 
 Acked-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]

Thanks! :)

 - Arnaldo
 

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel


[Devel] Re: [NETFILTER]: Unable to delete a SAME rule (Using SAME target problems)

2007-11-13 Thread Patrick McHardy

Konstantin Khorenko wrote:

Dear all,

The problem description: unable to delete a SAME target rule.

[...]
At the moment i can see only 3 ways of fixing this:
* reassemble struct ipt_same_info - put 'ipnum' and 'iparray' at the end of the
structure. This will save generic code both in kernel and userspace.

* let struct ipt_same_info be as is, teach userspace to manipulate more complex
masks (not only first X bytes of the structure)

* let struct ipt_same_info be as is, teach kernel to zero pointers and all the
fields which are used only in kernel.

All these ways are quite painful, but could someone please comment this - may
be i just missed and some decision had been already done on this issue?



Actually yes, thats why haven't got compat support for SAME yet.
Because of these issues and since SAME is obsolete nowadays I've
decided to put it on feature-removal-schedule instead of trying
to work around the problems, it will be removed at 1.1.08:

What:   iptables SAME target 


When:   1.1. 2008
Files:  net/ipv4/netfilter/ipt_SAME.c, 
include/linux/netfilter_ipv4/ipt_SAME.h
Why:Obsolete for multiple years now, NAT core provides the same 
behaviour.

Unfixable broken wrt. 32/64 bit cleanness.
Who:Patrick McHardy [EMAIL PROTECTED]

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel


[Devel] Re: [PATCH][NET] Convert init_timer into setup_timer

2007-11-13 Thread David Miller
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 11:43:40 -0200

 Em Tue, Nov 13, 2007 at 05:34:21AM -0800, David Miller escreveu:
  From: Pavel Emelyanov [EMAIL PROTECTED]
  Date: Tue, 13 Nov 2007 16:10:03 +0300
  
   Many-many code in the kernel initialized the timer-function 
   and  timer-data together with calling init_timer(timer). There 
   is already a helper for this. Use it for networking code.
   
   The patch is HUGE, but makes the code 130 lines shorter 
   (98 insertions(+), 228 deletions(-)).
   
   Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
  
  I have no objection to this patch, but it is 2.6.25
  material for sure.
 
 Agreed, Pavel, if you want please stick:
 
 Acked-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]

No need, I've applied it to net-2.6.25 :-)

___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel