* Re: [PATCH 5/7]: [NET]: Fix drivers to handle napi_disable() disabling interrupts.
From: David Miller @ 2008-01-09 6:44 UTC (permalink / raw)
To: pcnet32; +Cc: netdev
In-Reply-To: <1199859269.9002.6.camel@Linux.home>
From: Don Fry <pcnet32@verizon.net>
Date: Tue, 08 Jan 2008 22:14:29 -0800
> Tested pcnet32 on x86_64 box and see no problems with the change.
> The code is only exercised if doing loopback testing, or changing
> the ring size during a receive storm.
>
> Acked-by: Don Fry <pcnet32@verizon.net>
Thanks for testing and the feedback.
^ permalink raw reply
* Re: SACK scoreboard
From: Andi Kleen @ 2008-01-09 7:03 UTC (permalink / raw)
To: David Miller
Cc: andi, jheffner, ilpo.jarvinen, lachlan.andrew, netdev, quetchen
In-Reply-To: <20080108.223925.105105455.davem@davemloft.net>
> It adds severe spikes in CPU utilization that are even moderate
> line rates begins to affect RTTs.
>
> Or do you think it's OK to process 500,000 SKBs while locked
> in a software interrupt.
You can always push it into a work queue. Even put it to
other cores if you want.
In fact this is already done partly for the ->completion_queue.
Wouldn't be a big change to queue it another level down.
Also even freeing a lot of objects doesn't have to be
that expensive. I suspect the most cost is in taking
the slab locks, but that could be batched. Without
that the kmem_free fast path isn't particularly
expensive, as long as the headers are still in cache.
Long ago I had sk_buff optimized for the routing case so that freeing
can be all done with a single cache line. That is
long gone, but could be probably restored.
But asking for protocol changes just to work around such a
internal implementation detail is ... <I miss words>
> Perhaps you have another broken awk script to prove this :-)
Your hand waved numbers on inline sizes there were definitely worse
than mine.
-Andi
^ permalink raw reply
* Re: SACK scoreboard
From: David Miller @ 2008-01-09 7:16 UTC (permalink / raw)
To: andi; +Cc: jheffner, ilpo.jarvinen, lachlan.andrew, netdev, quetchen
In-Reply-To: <20080109070318.GA8581@one.firstfloor.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Wed, 9 Jan 2008 08:03:18 +0100
> Also even freeing a lot of objects doesn't have to be
> that expensive. I suspect the most cost is in taking
> the slab locks, but that could be batched.
We're touching SKB struct members, doing atomics on them, etc. for
objects we haven't referenced for at least two RTTs so are guarenteed
to be cache cold.
Let's say best case we can get it down to 2 cache line misses, and as
a very aggressive goal we can get the cost down to 100 cycles. For
500,000 packets this is 500 million cpu cycles to free them all up.
That's 1/4 of a second even on a 2 GHZ cpu.
And yes there are inherent costs in handling TCP windows that are
500,000 packets in size. But, that freeing cost should be spread
throughout the handling of the RTT feedback, not handled all at once.
> Your hand waved numbers on inline sizes there were definitely worse
> than mine.
Your primary objective seems to be "being right", and that's fine but
realize that it makes discussing anything with you about as fun as
picking one's toe nails with an ice axe.
Eventually you will be ignored by most folks who get fed up by this
style of argument.
So, have fun being right rather than being pleasant to work with.
^ permalink raw reply
* Re: [XFRM]: xfrm_algo_clone() allocates too much memory
From: Eric Dumazet @ 2008-01-09 7:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, netdev
In-Reply-To: <E1JCUDY-000791-00@gondolin.me.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]
Herbert Xu a écrit :
> Eric Dumazet <dada1@cosmosbay.com> wrote:
>> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
>> index 58dfa82..731f0a8 100644
>> --- a/include/net/xfrm.h
>> +++ b/include/net/xfrm.h
>> @@ -1188,10 +1188,15 @@ static inline int xfrm_aevent_is_on(void)
>> return ret;
>> }
>>
>> +static inline int alg_len(struct xfrm_algo *alg)
>
> Could you please add an xfrm prefix to this?
Sure, thanks for the suggestion :)
[XFRM]: xfrm_algo_clone() allocates too much memory
alg_key_len is the length in bits of the key, not in bytes.
Best way to fix this is to move alg_len() function from net/xfrm/xfrm_user.c
to include/net/xfrm.h, and to use it in xfrm_algo_clone()
alg_len() is renamed to xfrm_alg_len() because of its global exposition.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
include/net/xfrm.h | 7 ++++++-
net/xfrm/xfrm_user.c | 17 ++++++-----------
2 files changed, 12 insertions(+), 12 deletions(-)
[-- Attachment #2: xfrm_algo_clone.patch --]
[-- Type: text/plain, Size: 2471 bytes --]
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 58dfa82..1dd20cf 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1188,10 +1188,15 @@ static inline int xfrm_aevent_is_on(void)
return ret;
}
+static inline int xfrm_alg_len(struct xfrm_algo *alg)
+{
+ return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
+}
+
#ifdef CONFIG_XFRM_MIGRATE
static inline struct xfrm_algo *xfrm_algo_clone(struct xfrm_algo *orig)
{
- return (struct xfrm_algo *)kmemdup(orig, sizeof(*orig) + orig->alg_key_len, GFP_KERNEL);
+ return kmemdup(orig, xfrm_alg_len(orig), GFP_KERNEL);
}
static inline void xfrm_states_put(struct xfrm_state **states, int n)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index e75dbdc..c4f6419 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -31,11 +31,6 @@
#include <linux/in6.h>
#endif
-static inline int alg_len(struct xfrm_algo *alg)
-{
- return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
-}
-
static int verify_one_alg(struct nlattr **attrs, enum xfrm_attr_type_t type)
{
struct nlattr *rt = attrs[type];
@@ -45,7 +40,7 @@ static int verify_one_alg(struct nlattr **attrs, enum xfrm_attr_type_t type)
return 0;
algp = nla_data(rt);
- if (nla_len(rt) < alg_len(algp))
+ if (nla_len(rt) < xfrm_alg_len(algp))
return -EINVAL;
switch (type) {
@@ -204,7 +199,7 @@ static int attach_one_algo(struct xfrm_algo **algpp, u8 *props,
return -ENOSYS;
*props = algo->desc.sadb_alg_id;
- p = kmemdup(ualg, alg_len(ualg), GFP_KERNEL);
+ p = kmemdup(ualg, xfrm_alg_len(ualg), GFP_KERNEL);
if (!p)
return -ENOMEM;
@@ -516,9 +511,9 @@ static int copy_to_user_state_extra(struct xfrm_state *x,
NLA_PUT_U64(skb, XFRMA_LASTUSED, x->lastused);
if (x->aalg)
- NLA_PUT(skb, XFRMA_ALG_AUTH, alg_len(x->aalg), x->aalg);
+ NLA_PUT(skb, XFRMA_ALG_AUTH, xfrm_alg_len(x->aalg), x->aalg);
if (x->ealg)
- NLA_PUT(skb, XFRMA_ALG_CRYPT, alg_len(x->ealg), x->ealg);
+ NLA_PUT(skb, XFRMA_ALG_CRYPT, xfrm_alg_len(x->ealg), x->ealg);
if (x->calg)
NLA_PUT(skb, XFRMA_ALG_COMP, sizeof(*(x->calg)), x->calg);
@@ -1978,9 +1973,9 @@ static inline size_t xfrm_sa_len(struct xfrm_state *x)
{
size_t l = 0;
if (x->aalg)
- l += nla_total_size(alg_len(x->aalg));
+ l += nla_total_size(xfrm_alg_len(x->aalg));
if (x->ealg)
- l += nla_total_size(alg_len(x->ealg));
+ l += nla_total_size(xfrm_alg_len(x->ealg));
if (x->calg)
l += nla_total_size(sizeof(*x->calg));
if (x->encap)
^ permalink raw reply related
* Re: Please pull 'upstream-davem' branch of wireless-2.6
From: David Miller @ 2008-01-09 7:36 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080108192914.GA3086-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 8 Jan 2008 14:29:14 -0500
> Here are a few more for 2.6.25. The are mostly clean-ups for the new
> PID rate control algorithm, and some A-MPDU bits related to supporting
> 802.11n.
Pulled and pushed back out to net-2.6.25, thanks John.
^ permalink raw reply
* Re: [XFRM]: xfrm_algo_clone() allocates too much memory
From: David Miller @ 2008-01-09 7:40 UTC (permalink / raw)
To: dada1; +Cc: herbert, netdev
In-Reply-To: <478477C7.9030004@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Wed, 09 Jan 2008 08:29:11 +0100
Thanks for catching this.
Applied to net-2.6
> +static inline int xfrm_alg_len(struct xfrm_algo *alg)
> +{
> + return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
> +}
That gets emitted as a divide doesn't it :-))))
^ permalink raw reply
* [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
From: Eric Dumazet @ 2008-01-09 7:38 UTC (permalink / raw)
To: Herbert Xu, Paul E. McKenney; +Cc: davem, dipankar, netdev
In-Reply-To: <E1JCU1E-00076z-00@gondolin.me.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]
Herbert Xu a écrit :
> Eric Dumazet <dada1@cosmosbay.com> wrote:
>> Very good question, but honestly I really dont see why it was there at the
>> first place :
>
> It was there because someone went through this file and robotically
> replaced all conditional read barriers with rcu_dereference, even when
> it made zero sense.
>
> Basically you can add a conditional barrier either at the point where
> the pointer gets read, or where it gets derferenced. Previously we
> did the latter (except that the show function didn't have a barrier
> at all which is technically a bug though harmless in pratice). This
> patch moves it to the spot where it gets read which is also OK.
>
>> static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
>> {
>> - struct rt_cache_iter_state *st = rcu_dereference(seq->private);
>> + struct rt_cache_iter_state *st = seq->private;
>>
>> - r = r->u.dst.rt_next;
>> + r = rcu_dereference(r->u.dst.rt_next);
>> while (!r) {
>> rcu_read_unlock_bh();
>> if (--st->bucket < 0)
>> break;
>> rcu_read_lock_bh();
>> - r = rt_hash_table[st->bucket].chain;
>> + r = rcu_dereference(rt_hash_table[st->bucket].chain);
>> }
>> return r;
>
> Slight optimisation: please move both barriers onto the return statement,
> i.e.,
>
> return rcu_dereference(r);
I am not sure this is valid, since it will do this :
r = rt_hash_table[st->bucket].chain;
if (r)
return rcu_dereference(r);
So compiler might be dumb enough do dereference
&rt_hash_table[st->bucket].chain two times.
It seems Dipankar is busy at this moment, so I will post again the patch and
ask a comment from Paul :)
Thank you
[NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
In rt_cache_get_next(), no need to guard seq->private by a rcu_dereference()
since seq is private to the thread running this function. Reading seq.private
once (as guaranted bu rcu_dereference()) or several time if compiler really is
dumb enough wont change the result.
But we miss real spots where rcu_dereference() are needed, both in
rt_cache_get_first() and rt_cache_get_next()
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: route_rcu.patch --]
[-- Type: text/plain, Size: 1011 bytes --]
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d337706..3b7562f 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -278,7 +278,7 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
for (st->bucket = rt_hash_mask; st->bucket >= 0; --st->bucket) {
rcu_read_lock_bh();
- r = rt_hash_table[st->bucket].chain;
+ r = rcu_dereference(rt_hash_table[st->bucket].chain);
if (r)
break;
rcu_read_unlock_bh();
@@ -288,15 +288,15 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
{
- struct rt_cache_iter_state *st = rcu_dereference(seq->private);
+ struct rt_cache_iter_state *st = seq->private;
- r = r->u.dst.rt_next;
+ r = rcu_dereference(r->u.dst.rt_next);
while (!r) {
rcu_read_unlock_bh();
if (--st->bucket < 0)
break;
rcu_read_lock_bh();
- r = rt_hash_table[st->bucket].chain;
+ r = rcu_dereference(rt_hash_table[st->bucket].chain);
}
return r;
}
^ permalink raw reply related
* Re: [SOCK]: Adds a rcu_dereference() in sk_filter
From: David Miller @ 2008-01-09 7:41 UTC (permalink / raw)
To: herbert; +Cc: dada1, netdev, dim, kuznet
In-Reply-To: <E1JCUFO-00079j-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 09 Jan 2008 17:17:06 +1100
> Eric Dumazet <dada1@cosmosbay.com> wrote:
> >
> > It seems commit fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9 introduced a RCU
> > protection for sk_filter(), without a rcu_dereference()
> >
> > Either we need a rcu_dereference(), either a comment should explain why we
> > dont need it. I vote for the former.
> >
> > Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [XFRM]: xfrm_algo_clone() allocates too much memory
From: Eric Dumazet @ 2008-01-09 7:51 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev
In-Reply-To: <20080108.234012.181072357.davem@davemloft.net>
David Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Wed, 09 Jan 2008 08:29:11 +0100
>
> Thanks for catching this.
>
> Applied to net-2.6
>
>> +static inline int xfrm_alg_len(struct xfrm_algo *alg)
>> +{
>> + return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
>> +}
>
> That gets emitted as a divide doesn't it :-))))
>
>
Yes I have a patch for these divides, but will apply on 2.6.25 once this one
hits it. (this saves 192 bytes of kernel text BTW)
^ permalink raw reply
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: David Miller @ 2008-01-09 7:53 UTC (permalink / raw)
To: dlstevens; +Cc: brian.haley, netdev, netdev-owner, yoshfuji
In-Reply-To: <OF3393858D.9874E03A-ON882573CA.00071BC8-882573CA.000738ED@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Mon, 7 Jan 2008 17:18:56 -0800
> Acked-by: David L Stevens <dlstevens@us.ibm.com>
Patch applied, thanks everyone.
^ permalink raw reply
* Re: [XFRM]: xfrm_algo_clone() allocates too much memory
From: David Miller @ 2008-01-09 7:53 UTC (permalink / raw)
To: dada1; +Cc: herbert, netdev
In-Reply-To: <47847D0B.3050003@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Wed, 09 Jan 2008 08:51:39 +0100
> Yes I have a patch for these divides, but will apply on 2.6.25 once this one
> hits it. (this saves 192 bytes of kernel text BTW)
I never doubted you for a second.
^ permalink raw reply
* Re: [VLAN]: Avoid expensive divides
From: David Miller @ 2008-01-09 7:54 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <47835E74.4040900@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 08 Jan 2008 12:28:52 +0100
> We can avoid divides (as seen with CONFIG_CC_OPTIMIZE_FOR_SIZE=y on x86)
> changing vlan_group_get_device()/vlan_group_set_device() id parameter
> from signed to
> unsigned.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: SACK scoreboard
From: David Miller @ 2008-01-09 7:58 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: lachlan.andrew, netdev, quetchen
In-Reply-To: <Pine.LNX.4.64.0801081258050.12911@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 8 Jan 2008 14:12:47 +0200 (EET)
> If I'd hint my boss that I'm involved in something like this I'd
> bet that he also would get quite crazy... ;-) I'm partially paid
> for making TCP more RFCish :-), or at least that the places where
> thing diverge are known and controllable for research purposes.
RFCs are great guides by which to implement things, but they have been
often completely wrong or not practicle to follow strictly.
The handling of out of order ACKs with timestamps is my favorite
example. Nobody performs an RFC compliant timestamp check on ACK
packets, or else their performance would go into the toilet during
packet reordering.
The URG bit setting is another one.
Especially when, practically speaking, we can in fact make changes
like I believe we can here I think we should.
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Jay Vosburgh @ 2008-01-09 7:58 UTC (permalink / raw)
To: Krzysztof Oledzki
Cc: netdev, Jeff Garzik, David Miller, Andy Gospodarek, Herbert Xu
In-Reply-To: <Pine.LNX.4.64.0801090732490.1135@bizon.gios.gov.pl>
Krzysztof Oledzki <olel@ans.pl> wrote:
>Fine. Just let you know that someone test your patches and everything
>works, except mentioned problem.
And I appreciate it; I just wanted to make sure our many fans
following along at home didn't misunderstand.
Could you let me know if the patch below make the lockdep
warning go away? This applies on top of the previous three, although it
should be trivial to do by hand.
I'm still checking to make sure this is safe with regard to
mutexing the bonding structures, but it would be good to know if it
eliminates the warning.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 77d004d..1baaadc 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3937,8 +3937,6 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
struct bonding *bond = bond_dev->priv;
struct dev_mc_list *dmi;
- write_lock_bh(&bond->lock);
-
/*
* Do promisc before checking multicast_mode
*/
@@ -3978,8 +3976,6 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
/* save master's multicast list */
bond_mc_list_destroy(bond);
bond_mc_list_copy(bond_dev->mc_list, bond, GFP_ATOMIC);
-
- write_unlock_bh(&bond->lock);
}
/*
^ permalink raw reply related
* Re: [PATCH][VLAN] Merge tree equal tails in vlan_skb_recv
From: Pavel Emelyanov @ 2008-01-09 8:15 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Netdev List
In-Reply-To: <47591F9F.1020607@trash.net>
Hi, Patrick.
> Pavel Emelyanov wrote:
>> There are tree paths in it, that set the skb->proto and then
>> perform common receive manipulations (basically call netif_rx()).
>>
>> I think, that we can make this code flow easier to understand
>> by introducing the vlan_set_encap_proto() function (I hope the
>> name is good) to setup the skb proto and merge the paths calling
>> netif_rx() together.
>>
>> Surprisingly, but gcc detects this thing and merges these paths
>> by itself, so this patch doesn't make the vlan module smaller.
>
>
> I already have something similar queued, but your patch is a nice
> cleanup on top. I'll merge it into my tree and send it out after
> some testing, hopefully today.
>
What are your plans about this patch? Should I resubmit this one?
Thanks,
Pavel
^ permalink raw reply
* Re: [PATCH net-2.6.25] [IPV4] Remove unsupported DNAT (RTCF_NAT and RTCF_NAT) in IPV4
From: David Miller @ 2008-01-09 8:19 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0801021331w63637142sd39b6605bd6f8be4@mail.gmail.com>
From: "Rami Rosen" <ramirose@gmail.com>
Date: Wed, 2 Jan 2008 23:31:37 +0200
> - The DNAT (Destination NAT) is not implemented in IPV4.
>
> - This patch remove the code which checks these flags
> in net/ipv4/arp.c and net/ipv4/route.c.
>
> The RTCF_NAT and RTCF_NAT should stay in the header (linux/in_route.h)
> because they are used in DECnet.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks Rami.
If someone has the stamina, it's very likely that the partial
NAT support in the decnet code can simply be removed. If
successful, then the in_route.h macros can be removed.
^ permalink raw reply
* Re: [patch 5/9][NETNS][IPV6] make bindv6only sysctl per namespace
From: David Miller @ 2008-01-09 8:25 UTC (permalink / raw)
To: dlezcano; +Cc: benjamin.thery, netdev, dada1
In-Reply-To: <47825513.50100@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Mon, 07 Jan 2008 17:36:35 +0100
> Thanks Benjamin to catch this.
>
> I think I have to apologize to Eric, I thought I tested with this option
> off but it wasn't and Eric was right. I will wait a little for feedbacks
> and send a V3.
I would have preferred if you just reposted a fixed version of patch 5
instead of waiting for the feedback that realistically isn't going to
come at all after this much time has passed.
I was about to apply this series, then looked through my mailbox for
reported regressions and hit this.
That makes me not start applying your patch series. I want the whole
thing with known bug fixes available by the time I get around to
reviewing it.
Thanks.
^ permalink raw reply
* Re: make ipv6_sysctl_register to return a value
From: David Miller @ 2008-01-09 8:26 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <47828DEB.9070301@fr.ibm.com>
Why did you post this again? It's identical to patch 1/9
from the previous series you sent out.
This is confusing, since it makes me think you wanted me to
perhaps do something different or update an already
submitted patch.
^ permalink raw reply
* Re: [PATCH net-2.6.25 1/6][NET] Simple ctl_table to ctl_path conversions.
From: David Miller @ 2008-01-09 8:30 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47839CD1.4080505@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 08 Jan 2008 18:54:57 +0300
> This patch includes many places, that only required
> replacing the ctl_table-s with appropriate ctl_paths
> and call register_sysctl_paths().
>
> Nothing special was done with them.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 2/6][IPVS] Switch to using ctl_paths.
From: David Miller @ 2008-01-09 8:30 UTC (permalink / raw)
To: horms; +Cc: xemul, netdev, devel
In-Reply-To: <20080109024914.GG3403@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Wed, 9 Jan 2008 11:49:16 +0900
> On Tue, Jan 08, 2008 at 06:58:11PM +0300, Pavel Emelyanov wrote:
> > The feature of ipvs ctls is that the net/ipv4/vs path
> > is common for core ipvs ctls and for two schedulers,
> > so I make it exported and re-use it in modules.
> >
> > Two other .c files required linux/sysctl.h to make the
> > extern declaration of this path compile well.
> >
> > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Thanks, this looks good to me and I've confirmed that
> the same entires with the same permissions exist under
> /proc/sys/net/ipv4/vs before and after the change.
>
> Acked-by: Simon Horman <horms@verge.net.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-2.6.25 3/6][DECNET] Switch to using ctl_paths.
From: David Miller @ 2008-01-09 8:31 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47839E88.2040604@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 08 Jan 2008 19:02:16 +0300
> The decnet includes two places to patch. The first one is
> the net/decnet table itself, and it is patched just like
> other subsystems in the first patch in this series.
>
> The second place is a bit more complex - it is the
> net/decnet/conf/xxx entries,. similar to those in
> ipv4/devinet.c and ipv6/addrconf.c. This code is made similar
> to those in ipv[46].
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 4/6][AX25] Switch to using ctl_paths.
From: David Miller @ 2008-01-09 8:32 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47839F3E.5080109@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 08 Jan 2008 19:05:18 +0300
> This one is almost the same as the hunks in the
> first patch, but ax25 tables are created dynamically.
>
> So this patch differs a bit to handle this case.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 5/6][NETFILTER] Switch to using ctl_paths in nf_queue and conntrack modules
From: David Miller @ 2008-01-09 8:33 UTC (permalink / raw)
To: kaber; +Cc: xemul, netdev, devel
In-Reply-To: <4783A092.1040605@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 08 Jan 2008 17:10:58 +0100
> Pavel Emelyanov wrote:
> > This includes the most simple cases for netfilter.
> >
> > The first part is tne queue modules for ipv4 and ipv6,
> > on which the net/ipv4/ and net/ipv6/ paths are reused
> > from the appropriate ipv4 and ipv6 code.
> >
> > The conntrack module is also patched, but this hunk is
> > very small and simple.
> >
> > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Looks good to me.
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 6/6][NETFILTER] Use the ctl paths instead of hand-made analogue
From: David Miller @ 2008-01-09 8:34 UTC (permalink / raw)
To: kaber; +Cc: xemul, netdev, devel
In-Reply-To: <4783A12A.3060207@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 08 Jan 2008 17:13:30 +0100
> Pavel Emelyanov wrote:
> > The conntracks subsystem has a similar infrastructure
> > to maintain ctl_paths, but since we already have it
> > on the generic level, I think it's OK to switch to
> > using it.
> >
> > So, basically, this patch just replaces the ctl_table-s
> > with ctl_path-s, nf_register_sysctl_table with
> > register_sysctl_paths() and removes no longer needed code.
>
> Also looks good, thanks.
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25] [BRIDGE] Remove unused macros from ebt_vlan.c
From: David Miller @ 2008-01-09 8:35 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0801080638j48b51978j9beb11b310ef2b8@mail.gmail.com>
From: "Rami Rosen" <ramirose@gmail.com>
Date: Tue, 8 Jan 2008 16:38:15 +0200
> Remove two unused macros, INV_FLAG and SET_BITMASK
> from net/bridge/netfilter/ebt_vlan.c.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox