* Re: Bridge stays down until a port is added
From: Stephen Hemminger @ 2011-09-26 15:47 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
In-Reply-To: <20110925082504.GA32712@torres.zugschlus.de>
The root of this whole problem is really that IPv6 reports addresses
in a tentative state to applications that can not be passed to the bind() system call.
For most cases, this problem never happens because the tentative addresses are
resolved by Duplicate Address Detection before the application starts. But
I have seen (and fixed) this happen before this whole discussion started.
1. The problem is not unique to bridges. It happens with bridge, macvtap,
even on wireless networks where the device is available but carrier is
not asserted.
2. Any change to what the kernel does (like not reporting tentative addresses)
would break applications even worse.
3. When the bridge was always reporting carrier, it was in effect breaking
IPv6 Duplicate Address Detection. And that is bad.
^ permalink raw reply
* Re: intel 82599 multi-port performance
From: J.Hwan.Kim @ 2011-09-26 15:42 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <4E808A41.8040902@genband.com>
On 2011년 09월 26일 23:20, Chris Friesen wrote:
> On 09/26/2011 04:26 AM, J.Hwan Kim wrote:
>> Hi, everyone
>>
>> Now, I'm testing a network card including intel 82599.
>> In our experiment, with the driver modified with ixgbe and multi-port
>> enabled,
>
> What do you mean by "modified with ixgbe and multi-port enabled"? You
> shouldn't need to do anything special to use both ports.
>
>> rx performance of each port with 10Gbps of 64bytes frame is
>> a half than when only 1 port is used.
>
> Sounds like a cpu limitation. What is your cpu usage? How are your
> interrupts routed? Are you using multiple rx queues?
>
Our server is XEON 2.4GHz with 8 cores.
I'm using 4 RSS queues for each port and distributed it's interrupts to
different cores respectively.
I checked the CPU utilization with TOP, I guess ,it is not cpu imitation
problem.
^ permalink raw reply
* Question about memory leak detector giving false positive report for net/core/flow.c
From: Huajun Li @ 2011-09-26 15:17 UTC (permalink / raw)
To: Catalin Marinas, linux-mm; +Cc: "Eric Dumaze"t, netdev, Huajun Li
Memory leak detector gives following memory leak report, it seems the
report is triggered by net/core/flow.c, but actually, it should be a
false positive report.
So, is there any idea from kmemleak side to fix/disable this false
positive report like this?
Yes, kmemleak_not_leak(...) could disable it, but is it suitable for this case ?
BTW, I wrote a simple test code to emulate net/core/flow.c behavior at
this stage which triggers the report, and it could also make kmemleak
give similar report, please check below test code:
kernel version:
#uname -a
Linux 3.1.0-rc7 #22 SMP Tue Sep 26 05:43:01 CST 2011 x86_64 x86_64
x86_64 GNU/Linux
memory leak report:
-------------------------------------------------------------------------------------------
unreferenced object 0xffff880073a70000 (size 8192):
comm "swapper", pid 1, jiffies 4294937832 (age 445.740s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8124db64>] create_object+0x144/0x360
[<ffffffff8191192e>] kmemleak_alloc+0x7e/0x110
[<ffffffff81235b26>] __kmalloc_node+0x156/0x3a0
[<ffffffff81935512>] flow_cache_cpu_prepare.clone.1+0x58/0xc0
[<ffffffff8214c361>] flow_cache_init_global+0xb6/0x1af
[<ffffffff8100225d>] do_one_initcall+0x4d/0x260
[<ffffffff820ec2e9>] kernel_init+0x161/0x23a
[<ffffffff8194ab04>] kernel_thread_helper+0x4/0x10
[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff880073a74290 (size 8192):
comm "swapper", pid 1, jiffies 4294937832 (age 445.740s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8124db64>] create_object+0x144/0x360
[<ffffffff8191192e>] kmemleak_alloc+0x7e/0x110
[<ffffffff81235b26>] __kmalloc_node+0x156/0x3a0
[<ffffffff81935512>] flow_cache_cpu_prepare.clone.1+0x58/0xc0
[<ffffffff8214c361>] flow_cache_init_global+0xb6/0x1af
[<ffffffff8100225d>] do_one_initcall+0x4d/0x260
[<ffffffff820ec2e9>] kernel_init+0x161/0x23a
[<ffffffff8194ab04>] kernel_thread_helper+0x4/0x10
[<ffffffffffffffff>] 0xffffffffffffffff
Simple test code to reproduce a similar report:
-----------------------------------------------------------------------------------------
MODULE_LICENSE("GPL");
struct test {
int *pt;
};
static struct test __percpu *percpu;
static int __init test_init(void)
{
int i;
percpu = alloc_percpu(struct test);
if (!percpu)
return -ENOMEM;
for_each_online_cpu(i) {
struct test *p = per_cpu_ptr(percpu, i);
p->pt = kmalloc(sizeof(int), GFP_KERNEL);
}
return 0;
}
static void __exit test_exit(void)
{
int i;
for_each_possible_cpu(i) {
struct test *p = per_cpu_ptr(percpu, i);
if (p->pt)
kfree(p->pt);
}
if (percpu)
free_percpu(percpu);
}
module_init(test_init);
module_exit(test_exit);
^ permalink raw reply
* Re: [SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference (v2)
From: Neil Horman @ 2011-09-26 15:02 UTC (permalink / raw)
To: James Bottomley; +Cc: Dan Carpenter, netdev, linux-scsi
In-Reply-To: <1317047476.9560.0.camel@dabdike>
On Mon, Sep 26, 2011 at 09:31:15AM -0500, James Bottomley wrote:
> On Mon, 2011-09-26 at 10:20 -0400, Neil Horman wrote:
> > On Mon, Sep 26, 2011 at 04:40:48PM +0300, Dan Carpenter wrote:
> > > Hi Neil,
> > >
> > > c98bc57ee65b6 "[SCSI] cxgb3i: convert cdev->l2opt to use rcu to
> > > prevent NULL dereference (v2)" from linux-next introduces a usinging
> > > uninitialized variable bug.
> > >
> > > struct l2t_entry *t3_l2t_get(struct t3cdev *cdev, struct neighbour *neigh,
> > > struct net_device *dev)
> > > {
> > > - struct l2t_entry *e;
> > > - struct l2t_data *d = L2DATA(cdev);
> > > + struct l2t_entry *e = NULL;
> > > + struct l2t_data *d;
> > > u32 addr = *(u32 *) neigh->primary_key;
> > > int ifidx = neigh->dev->ifindex;
> > > int hash = arp_hash(addr, ifidx, d);
> > > ^
> > > Uninitialized variable.
> > >
> > > struct port_info *p = netdev_priv(dev);
> > > int smt_idx = p->port_id;
> > >
> > > + rcu_read_lock();
> > > + d = L2DATA(cdev);
> > > + if (!d)
> > > + goto done_rcu;
> > > +
> > >
> > > regards,
> > > dan carpenter
> > >
> >
> > Yup, thanks, you need this to9 fix the uninitalized var.
>
> I rolled this into the original.
>
Thank you!
Neil
> James
>
>
>
^ permalink raw reply
* Re: [PATCH v3 4/7] per-cgroup tcp buffers control
From: Andrew Vagin @ 2011-09-26 14:39 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill
In-Reply-To: <1316393805-3005-5-git-send-email-glommer@parallels.com>
We can't change net.ipv4.tcp_mem if a cgroup with memory controller
isn't mounted.
[root@dhcp-10-30-20-19 ~]# sysctl -w net.ipv4.tcp_mem="3 2 3"
error: "Invalid argument" setting key "net.ipv4.tcp_mem"
It's because tcp_max_memory is initialized in mem_cgroup_populate:
mem_cgroup_populate->register_kmem_files->sockets_populate->tcp_init_cgroup
> +int sockets_populate(struct cgroup *cgrp, struct cgroup_subsys *ss)
> +{
> + struct proto *proto;
> + int ret = 0;
> +
> + read_lock(&proto_list_lock);
> + list_for_each_entry(proto,&proto_list, node) {
> + if (proto->init_cgroup)
> + ret |= proto->init_cgroup(proto, cgrp, ss);
> + }
> + if (!ret)
> + goto out;
> +
> + list_for_each_entry_continue_reverse(proto,&proto_list, node)
> + if (proto->destroy_cgroup)
> + proto->destroy_cgroup(proto, cgrp, ss);
> +
> +out:
> + read_unlock(&proto_list_lock);
> + return ret;
> +}
> @@ -198,6 +203,21 @@ static int ipv4_tcp_mem(ctl_table *ctl, int write,
> if (ret)
> return ret;
>
> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
> + rcu_read_lock();
> + cg = mem_cgroup_from_task(current);
> + for (i = 0; i< 3; i++)
> + if (vec[i]> tcp_max_memory(cg)) {
> + rcu_read_unlock();
> + return -EINVAL;
> + }
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference (v2)
From: James Bottomley @ 2011-09-26 14:31 UTC (permalink / raw)
To: Neil Horman; +Cc: Dan Carpenter, netdev, linux-scsi
In-Reply-To: <20110926142052.GA18283@hmsreliant.think-freely.org>
On Mon, 2011-09-26 at 10:20 -0400, Neil Horman wrote:
> On Mon, Sep 26, 2011 at 04:40:48PM +0300, Dan Carpenter wrote:
> > Hi Neil,
> >
> > c98bc57ee65b6 "[SCSI] cxgb3i: convert cdev->l2opt to use rcu to
> > prevent NULL dereference (v2)" from linux-next introduces a usinging
> > uninitialized variable bug.
> >
> > struct l2t_entry *t3_l2t_get(struct t3cdev *cdev, struct neighbour *neigh,
> > struct net_device *dev)
> > {
> > - struct l2t_entry *e;
> > - struct l2t_data *d = L2DATA(cdev);
> > + struct l2t_entry *e = NULL;
> > + struct l2t_data *d;
> > u32 addr = *(u32 *) neigh->primary_key;
> > int ifidx = neigh->dev->ifindex;
> > int hash = arp_hash(addr, ifidx, d);
> > ^
> > Uninitialized variable.
> >
> > struct port_info *p = netdev_priv(dev);
> > int smt_idx = p->port_id;
> >
> > + rcu_read_lock();
> > + d = L2DATA(cdev);
> > + if (!d)
> > + goto done_rcu;
> > +
> >
> > regards,
> > dan carpenter
> >
>
> Yup, thanks, you need this to9 fix the uninitalized var.
I rolled this into the original.
James
^ permalink raw reply
* Re: intel 82599 multi-port performance
From: Chris Friesen @ 2011-09-26 14:20 UTC (permalink / raw)
To: J.Hwan Kim; +Cc: netdev
In-Reply-To: <4E805359.2080600@gmail.com>
On 09/26/2011 04:26 AM, J.Hwan Kim wrote:
> Hi, everyone
>
> Now, I'm testing a network card including intel 82599.
> In our experiment, with the driver modified with ixgbe and multi-port
> enabled,
What do you mean by "modified with ixgbe and multi-port enabled"? You
shouldn't need to do anything special to use both ports.
> rx performance of each port with 10Gbps of 64bytes frame is
> a half than when only 1 port is used.
Sounds like a cpu limitation. What is your cpu usage? How are your
interrupts routed? Are you using multiple rx queues?
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: [SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference (v2)
From: Neil Horman @ 2011-09-26 14:20 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev, linux-scsi
In-Reply-To: <20110926134048.GA10999@longonot.mountain>
On Mon, Sep 26, 2011 at 04:40:48PM +0300, Dan Carpenter wrote:
> Hi Neil,
>
> c98bc57ee65b6 "[SCSI] cxgb3i: convert cdev->l2opt to use rcu to
> prevent NULL dereference (v2)" from linux-next introduces a usinging
> uninitialized variable bug.
>
> struct l2t_entry *t3_l2t_get(struct t3cdev *cdev, struct neighbour *neigh,
> struct net_device *dev)
> {
> - struct l2t_entry *e;
> - struct l2t_data *d = L2DATA(cdev);
> + struct l2t_entry *e = NULL;
> + struct l2t_data *d;
> u32 addr = *(u32 *) neigh->primary_key;
> int ifidx = neigh->dev->ifindex;
> int hash = arp_hash(addr, ifidx, d);
> ^
> Uninitialized variable.
>
> struct port_info *p = netdev_priv(dev);
> int smt_idx = p->port_id;
>
> + rcu_read_lock();
> + d = L2DATA(cdev);
> + if (!d)
> + goto done_rcu;
> +
>
> regards,
> dan carpenter
>
Yup, thanks, you need this to9 fix the uninitalized var.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
l2t.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/cxgb3/l2t.c b/drivers/net/cxgb3/l2t.c
index 3808f99..4154097 100644
--- a/drivers/net/cxgb3/l2t.c
+++ b/drivers/net/cxgb3/l2t.c
@@ -302,9 +302,9 @@ struct l2t_entry *t3_l2t_get(struct t3cdev *cdev, struct neighbour *neigh,
{
struct l2t_entry *e = NULL;
struct l2t_data *d;
+ int hash;
u32 addr = *(u32 *) neigh->primary_key;
int ifidx = neigh->dev->ifindex;
- int hash = arp_hash(addr, ifidx, d);
struct port_info *p = netdev_priv(dev);
int smt_idx = p->port_id;
@@ -313,6 +313,8 @@ struct l2t_entry *t3_l2t_get(struct t3cdev *cdev, struct neighbour *neigh,
if (!d)
goto done_rcu;
+ hash = arp_hash(addr, ifidx, d);
+
write_lock_bh(&d->lock);
for (e = d->l2tab[hash].first; e; e = e->next)
if (e->addr == addr && e->ifindex == ifidx &&
^ permalink raw reply related
* re: [SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference (v2)
From: Dan Carpenter @ 2011-09-26 13:40 UTC (permalink / raw)
To: nhorman; +Cc: netdev, linux-scsi
Hi Neil,
c98bc57ee65b6 "[SCSI] cxgb3i: convert cdev->l2opt to use rcu to
prevent NULL dereference (v2)" from linux-next introduces a usinging
uninitialized variable bug.
struct l2t_entry *t3_l2t_get(struct t3cdev *cdev, struct neighbour *neigh,
struct net_device *dev)
{
- struct l2t_entry *e;
- struct l2t_data *d = L2DATA(cdev);
+ struct l2t_entry *e = NULL;
+ struct l2t_data *d;
u32 addr = *(u32 *) neigh->primary_key;
int ifidx = neigh->dev->ifindex;
int hash = arp_hash(addr, ifidx, d);
^
Uninitialized variable.
struct port_info *p = netdev_priv(dev);
int smt_idx = p->port_id;
+ rcu_read_lock();
+ d = L2DATA(cdev);
+ if (!d)
+ goto done_rcu;
+
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] tcp: ECN blackhole should not force quickack mode
From: Eric Dumazet @ 2011-09-26 12:44 UTC (permalink / raw)
To: jhs
Cc: David Miller, netdev, Jerry Chu, Ilpo Järvinen, Jim Gettys,
Dave Taht
In-Reply-To: <1317038443.1865.40.camel@mojatatu>
Le lundi 26 septembre 2011 à 08:00 -0400, jamal a écrit :
> On Mon, 2011-09-26 at 10:26 +0200, Eric Dumazet wrote:
>
> > This refers to additions to RFC 2481 : This was refined by RFC 3168, and
> > the retransmitted TCP packets requirement is part of the final RFC :
>
> Ah, yes - thats where it went.
>
> >
> > BTW, the ECN+ proposal (RFC 5562 : Adding Explicit Congestion
> > Notification (ECN) Capability to TCP's SYN/ACK Packets) would allow the
> > client (receiving SYNACK message with ECT flags) to set the TCP_ECN_SEEN
> > I added in my patch, allowing even the first (retransmitted) data packet
> > to trigger quickack mode.
>
> Excellent ;->
> Are you going to add 5562 support?
I sent a private mail to Adam Langley this morning asking him if he
planned an official submission of a prior patch :
http://www.ietf.org/mail-archive/web/tcpm/current/msg03988.html
If Adam is too busy or not anymore interested, I would like to spend
some cycles on this.
Thanks
^ permalink raw reply
* Re: [PATCH] tcp: ECN blackhole should not force quickack mode
From: jamal @ 2011-09-26 12:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Jerry Chu, Ilpo Järvinen, Jim Gettys,
Dave Taht
In-Reply-To: <1317025614.2557.7.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 2011-09-26 at 10:26 +0200, Eric Dumazet wrote:
> This refers to additions to RFC 2481 : This was refined by RFC 3168, and
> the retransmitted TCP packets requirement is part of the final RFC :
Ah, yes - thats where it went.
>
> BTW, the ECN+ proposal (RFC 5562 : Adding Explicit Congestion
> Notification (ECN) Capability to TCP's SYN/ACK Packets) would allow the
> client (receiving SYNACK message with ECT flags) to set the TCP_ECN_SEEN
> I added in my patch, allowing even the first (retransmitted) data packet
> to trigger quickack mode.
Excellent ;->
Are you going to add 5562 support?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v3 6/7] tcp buffer limitation: per-cgroup limit
From: KAMEZAWA Hiroyuki @ 2011-09-26 11:02 UTC (permalink / raw)
To: Glauber Costa
Cc: Greg Thelen, linux-kernel, paul, lizf, ebiederm, davem, netdev,
linux-mm, kirill
In-Reply-To: <4E7DDB82.3030802@parallels.com>
On Sat, 24 Sep 2011 10:30:42 -0300
Glauber Costa <glommer@parallels.com> wrote:
> On 09/22/2011 03:01 AM, Greg Thelen wrote:
> > On Sun, Sep 18, 2011 at 5:56 PM, Glauber Costa<glommer@parallels.com> wrote:
> >> +static inline bool mem_cgroup_is_root(struct mem_cgroup *mem)
> >> +{
> >> + return (mem == root_mem_cgroup);
> >> +}
> >> +
> >
> > Why are you adding a copy of mem_cgroup_is_root(). I see one already
> > in v3.0. Was it deleted in a previous patch?
>
> Already answered by another good samaritan.
>
> >> +static int tcp_write_maxmem(struct cgroup *cgrp, struct cftype *cft, u64 val)
> >> +{
> >> + struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
> >> + struct mem_cgroup *parent = parent_mem_cgroup(sg);
> >> + struct net *net = current->nsproxy->net_ns;
> >> + int i;
> >> +
> >> + if (!cgroup_lock_live_group(cgrp))
> >> + return -ENODEV;
> >
> > Why is cgroup_lock_live_cgroup() needed here? Does it protect updates
> > to sg->tcp_prot_mem[*]?
> >
> >> +static u64 tcp_read_maxmem(struct cgroup *cgrp, struct cftype *cft)
> >> +{
> >> + struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
> >> + u64 ret;
> >> +
> >> + if (!cgroup_lock_live_group(cgrp))
> >> + return -ENODEV;
> >
> > Why is cgroup_lock_live_cgroup() needed here? Does it protect updates
> > to sg->tcp_max_memory?
>
> No, that is not my understanding. My understanding is this lock is
> needed to protect against the cgroup just disappearing under our nose.
>
Hm. reference count of dentry for cgroup isn't enough ?
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 4/7] per-cgroup tcp buffers control
From: KAMEZAWA Hiroyuki @ 2011-09-26 10:59 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill
In-Reply-To: <1316393805-3005-5-git-send-email-glommer@parallels.com>
On Sun, 18 Sep 2011 21:56:42 -0300
Glauber Costa <glommer@parallels.com> wrote:
> With all the infrastructure in place, this patch implements
> per-cgroup control for tcp memory pressure handling.
>
> Signed-off-by: Glauber Costa <glommer@parallels.com>
> CC: David S. Miller <davem@davemloft.net>
> CC: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
> CC: Eric W. Biederman <ebiederm@xmission.com>
a comment below.
> +int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
> + struct cgroup_subsys *ss)
> +{
> + struct mem_cgroup *cg = mem_cgroup_from_cont(cgrp);
> + unsigned long limit;
> +
> + cg->tcp_memory_pressure = 0;
> + atomic_long_set(&cg->tcp_memory_allocated, 0);
> + percpu_counter_init(&cg->tcp_sockets_allocated, 0);
> +
> + limit = nr_free_buffer_pages() / 8;
> + limit = max(limit, 128UL);
> +
> + cg->tcp_prot_mem[0] = sysctl_tcp_mem[0];
> + cg->tcp_prot_mem[1] = sysctl_tcp_mem[1];
> + cg->tcp_prot_mem[2] = sysctl_tcp_mem[2];
> +
Then, the parameter doesn't inherit parent's one ?
I think sockets_populate should pass 'parent' and
I think you should have a function
mem_cgroup_should_inherit_parent_settings(parent)
(This is because you made this feature as a part of memcg.
please provide expected behavior.)
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: KAMEZAWA Hiroyuki @ 2011-09-26 10:52 UTC (permalink / raw)
To: Glauber Costa
Cc: Balbir Singh, Greg Thelen, linux-kernel, paul, lizf, ebiederm,
davem, netdev, linux-mm, kirill
In-Reply-To: <4E7DECF0.9050804@parallels.com>
On Sat, 24 Sep 2011 11:45:04 -0300
Glauber Costa <glommer@parallels.com> wrote:
> On 09/22/2011 12:09 PM, Balbir Singh wrote:
> > On Thu, Sep 22, 2011 at 11:30 AM, Greg Thelen<gthelen@google.com> wrote:
> >> On Wed, Sep 21, 2011 at 11:59 AM, Glauber Costa<glommer@parallels.com> wrote:
> >>> Right now I am working under the assumption that tasks are long lived inside
> >>> the cgroup. Migration potentially introduces some nasty locking problems in
> >>> the mem_schedule path.
> >>>
> >>> Also, unless I am missing something, the memcg already has the policy of
> >>> not carrying charges around, probably because of this very same complexity.
> >>>
> >>> True that at least it won't EBUSY you... But I think this is at least a way
> >>> to guarantee that the cgroup under our nose won't disappear in the middle of
> >>> our allocations.
> >>
> >> Here's the memcg user page behavior using the same pattern:
> >>
> >> 1. user page P is allocate by task T in memcg M1
> >> 2. T is moved to memcg M2. The P charge is left behind still charged
> >> to M1 if memory.move_charge_at_immigrate=0; or the charge is moved to
> >> M2 if memory.move_charge_at_immigrate=1.
> >> 3. rmdir M1 will try to reclaim P (if P was left in M1). If unable to
> >> reclaim, then P is recharged to parent(M1).
> >>
> >
> > We also have some magic in page_referenced() to remove pages
> > referenced from different containers. What we do is try not to
> > penalize a cgroup if another cgroup is referencing this page and the
> > page under consideration is being reclaimed from the cgroup that
> > touched it.
> >
> > Balbir Singh
> Do you guys see it as a showstopper for this series to be merged, or can
> we just TODO it ?
>
In my experience, 'I can't rmdir cgroup.' is always an important/difficult
problem. The users cannot know where the accouting is leaking other than
kmem.usage_in_bytes or memory.usage_in_bytes. and can't fix the issue.
please add EXPERIMENTAL to Kconfig until this is fixed.
> I can push a proposal for it, but it would be done in a separate patch
> anyway. Also, we may be in better conditions to fix this when the slab
> part is merged - since it will likely have the same problems...
>
Yes. considering sockets which can be shared between tasks(cgroups)
you'll finally need
- owner task of socket
- account moving callback
Or disallow task moving once accounted.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: KAMEZAWA Hiroyuki @ 2011-09-26 10:34 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill
In-Reply-To: <1316393805-3005-2-git-send-email-glommer@parallels.com>
On Sun, 18 Sep 2011 21:56:39 -0300
Glauber Costa <glommer@parallels.com> wrote:
> This patch lays down the foundation for the kernel memory component
> of the Memory Controller.
>
> As of today, I am only laying down the following files:
>
> * memory.independent_kmem_limit
> * memory.kmem.limit_in_bytes (currently ignored)
> * memory.kmem.usage_in_bytes (always zero)
>
> Signed-off-by: Glauber Costa <glommer@parallels.com>
> CC: Paul Menage <paul@paulmenage.org>
> CC: Greg Thelen <gthelen@google.com>
I'm sorry that my slow review is delaying you.
> ---
> Documentation/cgroups/memory.txt | 30 +++++++++-
> init/Kconfig | 11 ++++
> mm/memcontrol.c | 115 ++++++++++++++++++++++++++++++++++++--
> 3 files changed, 148 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
> index 6f3c598..6f1954a 100644
> --- a/Documentation/cgroups/memory.txt
> +++ b/Documentation/cgroups/memory.txt
> @@ -44,8 +44,9 @@ Features:
> - oom-killer disable knob and oom-notifier
> - Root cgroup has no limit controls.
>
> - Kernel memory and Hugepages are not under control yet. We just manage
> - pages on LRU. To add more controls, we have to take care of performance.
> + Hugepages is not under control yet. We just manage pages on LRU. To add more
> + controls, we have to take care of performance. Kernel memory support is work
> + in progress, and the current version provides basically functionality.
>
> Brief summary of control files.
>
> @@ -56,8 +57,11 @@ Brief summary of control files.
> (See 5.5 for details)
> memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
> (See 5.5 for details)
> + memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.
> + (See 2.7 for details)
> memory.limit_in_bytes # set/show limit of memory usage
> memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
> + memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory
> memory.failcnt # show the number of memory usage hits limits
> memory.memsw.failcnt # show the number of memory+Swap hits limits
> memory.max_usage_in_bytes # show max memory usage recorded
> @@ -72,6 +76,9 @@ Brief summary of control files.
> memory.oom_control # set/show oom controls.
> memory.numa_stat # show the number of memory usage per numa node
>
> + memory.independent_kmem_limit # select whether or not kernel memory limits are
> + independent of user limits
> +
> 1. History
>
> The memory controller has a long history. A request for comments for the memory
> @@ -255,6 +262,25 @@ When oom event notifier is registered, event will be delivered.
> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
> zone->lru_lock, it has no lock of its own.
>
> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
> +
> + With the Kernel memory extension, the Memory Controller is able to limit
> +the amount of kernel memory used by the system. Kernel memory is fundamentally
> +different than user memory, since it can't be swapped out, which makes it
> +possible to DoS the system by consuming too much of this precious resource.
> +Kernel memory limits are not imposed for the root cgroup.
> +
> +Memory limits as specified by the standard Memory Controller may or may not
> +take kernel memory into consideration. This is achieved through the file
> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
> +memory to be controlled separately.
> +
> +When kernel memory limits are not independent, the limit values set in
> +memory.kmem files are ignored.
> +
> +Currently no soft limit is implemented for kernel memory. It is future work
> +to trigger slab reclaim when those limits are reached.
> +
> 3. User Interface
>
> 0. Configuration
> diff --git a/init/Kconfig b/init/Kconfig
> index d627783..49e5839 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -689,6 +689,17 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED
> For those who want to have the feature enabled by default should
> select this option (if, for some reason, they need to disable it
> then swapaccount=0 does the trick).
> +config CGROUP_MEM_RES_CTLR_KMEM
> + bool "Memory Resource Controller Kernel Memory accounting"
> + depends on CGROUP_MEM_RES_CTLR
> + default y
> + help
> + The Kernel Memory extension for Memory Resource Controller can limit
> + the amount of memory used by kernel objects in the system. Those are
> + fundamentally different from the entities handled by the standard
> + Memory Controller, which are page-based, and can be swapped. Users of
> + the kmem extension can use it to guarantee that no group of processes
> + will ever exhaust kernel resources alone.
>
> config CGROUP_PERF
> bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ebd1e86..d32e931 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -73,7 +73,11 @@ static int really_do_swap_account __initdata = 0;
> #define do_swap_account (0)
> #endif
>
> -
> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
> +int do_kmem_account __read_mostly = 1;
> +#else
> +#define do_kmem_account 0
> +#endif
Hmm, do we really need this boot option ?
>From my experience to have swap-accounting boot option,
this scares us ;) I think config is enough.
> /*
> * Statistics for memory cgroup.
> */
> @@ -270,6 +274,10 @@ struct mem_cgroup {
> */
> struct res_counter memsw;
> /*
> + * the counter to account for kmem usage.
> + */
> + struct res_counter kmem;
> + /*
> * Per cgroup active and inactive list, similar to the
> * per zone LRU lists.
> */
> @@ -321,6 +329,11 @@ struct mem_cgroup {
> */
> unsigned long move_charge_at_immigrate;
> /*
> + * Should kernel memory limits be stabilished independently
> + * from user memory ?
> + */
> + int kmem_independent;
> + /*
> * percpu counter.
> */
> struct mem_cgroup_stat_cpu *stat;
> @@ -388,9 +401,14 @@ enum charge_type {
> };
>
> /* for encoding cft->private value on file */
> -#define _MEM (0)
> -#define _MEMSWAP (1)
> -#define _OOM_TYPE (2)
> +
> +enum mem_type {
> + _MEM = 0,
> + _MEMSWAP,
> + _OOM_TYPE,
> + _KMEM,
> +};
> +
ok, nice clean up.
> #define MEMFILE_PRIVATE(x, val) (((x) << 16) | (val))
> #define MEMFILE_TYPE(val) (((val) >> 16) & 0xffff)
> #define MEMFILE_ATTR(val) ((val) & 0xffff)
> @@ -3943,10 +3961,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
> u64 val;
>
> if (!mem_cgroup_is_root(mem)) {
> + val = 0;
> + if (!mem->kmem_independent)
> + val = res_counter_read_u64(&mem->kmem, RES_USAGE);
> if (!swap)
> - return res_counter_read_u64(&mem->res, RES_USAGE);
> + val += res_counter_read_u64(&mem->res, RES_USAGE);
> else
> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
> + val += res_counter_read_u64(&mem->memsw, RES_USAGE);
> +
> + return val;
> }
>
> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
> @@ -3979,6 +4002,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
> else
> val = res_counter_read_u64(&mem->memsw, name);
> break;
> + case _KMEM:
> + val = res_counter_read_u64(&mem->kmem, name);
> + break;
> +
> default:
> BUG();
> break;
> @@ -4756,6 +4783,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
> return 0;
> }
>
> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
> +static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
> +{
> + return mem_cgroup_from_cont(cont)->kmem_independent;
> +}
> +
> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
> + u64 val)
> +{
> + cgroup_lock();
> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
> + cgroup_unlock();
Hm. This code allows that parent/child can have different settings.
Could you add parent-child check as..
"If parent sets use_hierarchy==1, children must have the same kmem_independent value
with parant's one."
How do you think ? I think a hierarchy must have the same config.
BTW...I don't like naming a little ;)
memory->consolidated/shared/?????_kmem_accounting ?
Or
memory->kmem_independent_accounting ?
or some better naming ?
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* intel 82599 multi-port performance
From: J.Hwan Kim @ 2011-09-26 10:26 UTC (permalink / raw)
To: netdev
Hi, everyone
Now, I'm testing a network card including intel 82599.
In our experiment, with the driver modified with ixgbe and multi-port
enabled,
rx performance of each port with 10Gbps of 64bytes frame is
a half than when only 1 port is used.
The pcie of our server is GEN2 (5x X 8).
Is the result reasonable?
When multi-ports are enabled and 10G stream is inserted to each port,
the maximum performance of each port is a half in our experiment.
Do you think it is a problem of our modified driver or the performance
bottleneck of 82599?
Now I cannot understand our experiment result.
Please give me an advice.
Thanks in advance.
Best Regards,
J.Hwan Kim
^ permalink raw reply
* Re: [PATCH 1/2] net: Disable false positive memory leak report
From: Eric Dumazet @ 2011-09-26 9:46 UTC (permalink / raw)
To: Huajun Li; +Cc: David Miller, netdev
In-Reply-To: <CA+v9cxZk_bsxrnn8zS-viH-0Wozz-T0XiFB0AE1fOOKqjcQ2ZQ@mail.gmail.com>
Le lundi 26 septembre 2011 à 16:42 +0800, Huajun Li a écrit :
> Eric, thanks for your response. :)
>
> 2011/9/26 Eric Dumazet <eric.dumazet@gmail.com>:
> > This makes no sense to me.
> >
> > per-cpu variables are taken into account by kmemleak.
> >
>
> Yes, I think so.
>
> > If not, you should report this problem to kmemleak maintainer.
> >
>
> To deal with false positives/negatives, in kmemleak document, it says:
> ...
> The false positives are objects wrongly reported as being memory leaks
> (orphan). For objects known not to be leaks, kmemleak provides the
> kmemleak_not_leak function. The kmemleak_ignore could also be used if
> the memory block is known not to contain other pointers and it will no
> longer be scanned.
> ...
>
But this interface should be only used in very specific situations, not
for transient kmemleak reports.
(When the pointer to allocated block is not stored in memory, or only
stored in the object itself : A detached area of memory)
AFAIK, its almost never used :
# git grep kmemleak_not_leak
Documentation/kmemleak.txt:kmemleak_not_leak - mark an object as not a leak
Documentation/kmemleak.txt:kmemleak_not_leak function. The kmemleak_ignore could also be used if
arch/sparc/kernel/irq_64.c: kmemleak_not_leak(bucket);
fs/block_dev.c: kmemleak_not_leak(bd_mnt);
fs/nfs/dir.c: kmemleak_not_leak(string->name);
include/linux/kmemleak.h:extern void kmemleak_not_leak(const void *ptr) __ref;
include/linux/kmemleak.h:static inline void kmemleak_not_leak(const void *ptr)
kernel/module.c: kmemleak_not_leak(ptr);
mm/kmemleak.c: * kmemleak_not_leak - mark an allocated object as false positive
mm/kmemleak.c:void __ref kmemleak_not_leak(const void *ptr)
mm/kmemleak.c:EXPORT_SYMBOL(kmemleak_not_leak);
mm/kmemleak.c: kmemleak_not_leak(log->ptr);
mm/page_cgroup.c: kmemleak_not_leak(base);
percpu variables are not specific these days, and kmemleak definitely
knows about them.
> For some scenarios, _maybe_ it's hard for kmemleak to give report
> exactly, and I think it is known issue for the maintainers, so hope
> there will be a powerful version soon. :)
> However, before the new version of kmemleak(if there is new version)
> comes, is it possible to disable this false positive report as other
> components? You know, other guys maybe also check the code once they
> meet the report again just like me.
We are not going to add patches to work around a core (kmemleak) issue,
especially without kmemleak maintainer feedback.
^ permalink raw reply
* [ANNOUNCE] ipvs and ipvs-next trees on github
From: Simon Horman @ 2011-09-26 9:10 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Hi,
Like many others I have put some trees up on github to see me
through until kernel.org becomes operation again.
Please base any critical bug fixes for the current rc kernel on
git://github.com/horms/ipvs.git
Please base any other changes on
git://github.com/horms/ipvs-next.git
These trees are currently based on David Miller's net and net-next
trees respectively and follow the same rules for accepting changes
as those trees.
^ permalink raw reply
* [PATCH 3/5] IPVS: Remove unused parameter from ip_vs_confirm_conntrack()
From: Simon Horman @ 2011-09-26 9:05 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, David S. Miller, Simon Horman
In-Reply-To: <1317027938-22053-1-git-send-email-horms@verge.net.au>
Acked-by: Julian Anastasov <ja@ssi.bg>
Acked-by Hans Schillstrom <hans@schillstrom.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 5 ++---
net/netfilter/ipvs/ip_vs_nfct.c | 2 +-
net/netfilter/ipvs/ip_vs_xmit.c | 2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 1aaf915..a5f0f6b 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1377,7 +1377,7 @@ static inline int ip_vs_conntrack_enabled(struct netns_ipvs *ipvs)
extern void ip_vs_update_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp,
int outin);
-extern int ip_vs_confirm_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp);
+extern int ip_vs_confirm_conntrack(struct sk_buff *skb);
extern void ip_vs_nfct_expect_related(struct sk_buff *skb, struct nf_conn *ct,
struct ip_vs_conn *cp, u_int8_t proto,
const __be16 port, int from_rs);
@@ -1395,8 +1395,7 @@ static inline void ip_vs_update_conntrack(struct sk_buff *skb,
{
}
-static inline int ip_vs_confirm_conntrack(struct sk_buff *skb,
- struct ip_vs_conn *cp)
+static inline int ip_vs_confirm_conntrack(struct sk_buff *skb);
{
return NF_ACCEPT;
}
diff --git a/net/netfilter/ipvs/ip_vs_nfct.c b/net/netfilter/ipvs/ip_vs_nfct.c
index f454c80..022e77e 100644
--- a/net/netfilter/ipvs/ip_vs_nfct.c
+++ b/net/netfilter/ipvs/ip_vs_nfct.c
@@ -127,7 +127,7 @@ ip_vs_update_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp, int outin)
nf_conntrack_alter_reply(ct, &new_tuple);
}
-int ip_vs_confirm_conntrack(struct sk_buff *skb, struct ip_vs_conn *cp)
+int ip_vs_confirm_conntrack(struct sk_buff *skb)
{
return nf_conntrack_confirm(skb);
}
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index ee319a4..aa2d720 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -339,7 +339,7 @@ ip_vs_dst_reset(struct ip_vs_dest *dest)
\
(skb)->ipvs_property = 1; \
if (unlikely((cp)->flags & IP_VS_CONN_F_NFCT)) \
- __ret = ip_vs_confirm_conntrack(skb, cp); \
+ __ret = ip_vs_confirm_conntrack(skb); \
if (__ret == NF_ACCEPT) { \
nf_reset(skb); \
skb_forward_csum(skb); \
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/5] ipvs: Expose ip_vs_ftp module parameters via sysfs.
From: Simon Horman @ 2011-09-26 9:05 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, David S. Miller, Krzysztof Wilczynski,
Simon Horman
In-Reply-To: <1317027938-22053-1-git-send-email-horms@verge.net.au>
From: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
This is to expose "ports" parameter via sysfs so it can be read
at any time in order to determine what port or ports were passed
to the module at the point when it was loaded.
Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ftp.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
index 4490a32..538d74e 100644
--- a/net/netfilter/ipvs/ip_vs_ftp.c
+++ b/net/netfilter/ipvs/ip_vs_ftp.c
@@ -52,8 +52,9 @@
* List of ports (up to IP_VS_APP_MAX_PORTS) to be handled by helper
* First port is set to the default port.
*/
+static unsigned int ports_count = 1;
static unsigned short ports[IP_VS_APP_MAX_PORTS] = {21, 0};
-module_param_array(ports, ushort, NULL, 0);
+module_param_array(ports, ushort, &ports_count, 0444);
MODULE_PARM_DESC(ports, "Ports to monitor for FTP control commands");
@@ -449,7 +450,7 @@ static int __net_init __ip_vs_ftp_init(struct net *net)
if (ret)
goto err_exit;
- for (i=0; i<IP_VS_APP_MAX_PORTS; i++) {
+ for (i = 0; i < ports_count; i++) {
if (!ports[i])
continue;
ret = register_ip_vs_app_inc(net, app, app->protocol, ports[i]);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 5/5] IPVS: Removed unused variables
From: Simon Horman @ 2011-09-26 9:05 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, David S. Miller, Simon Horman
In-Reply-To: <1317027938-22053-1-git-send-email-horms@verge.net.au>
ipvs is not used in ip_vs_genl_set_cmd() or ip_vs_genl_get_cmd()
Acked-by: Julian Anastasov <ja@ssi.bg>
Acked-by Hans Schillstrom <hans@schillstrom.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ctl.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 2b771dc..8f8aa30 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3279,10 +3279,8 @@ static int ip_vs_genl_set_cmd(struct sk_buff *skb, struct genl_info *info)
int ret = 0, cmd;
int need_full_svc = 0, need_full_dest = 0;
struct net *net;
- struct netns_ipvs *ipvs;
net = skb_sknet(skb);
- ipvs = net_ipvs(net);
cmd = info->genlhdr->cmd;
mutex_lock(&__ip_vs_mutex);
@@ -3392,10 +3390,8 @@ static int ip_vs_genl_get_cmd(struct sk_buff *skb, struct genl_info *info)
void *reply;
int ret, cmd, reply_cmd;
struct net *net;
- struct netns_ipvs *ipvs;
net = skb_sknet(skb);
- ipvs = net_ipvs(net);
cmd = info->genlhdr->cmd;
if (cmd == IPVS_CMD_GET_SERVICE)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 4/5] IPVS: Remove unused return value of protocol state transitions
From: Simon Horman @ 2011-09-26 9:05 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, David S. Miller, Simon Horman
In-Reply-To: <1317027938-22053-1-git-send-email-horms@verge.net.au>
Acked-by: Julian Anastasov <ja@ssi.bg>
Acked-by Hans Schillstrom <hans@schillstrom.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 6 +++---
net/netfilter/ipvs/ip_vs_core.c | 13 ++++++-------
net/netfilter/ipvs/ip_vs_proto_sctp.c | 14 ++++----------
net/netfilter/ipvs/ip_vs_proto_tcp.c | 6 ++----
net/netfilter/ipvs/ip_vs_proto_udp.c | 5 ++---
5 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index a5f0f6b..139784e 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -425,9 +425,9 @@ struct ip_vs_protocol {
const char *(*state_name)(int state);
- int (*state_transition)(struct ip_vs_conn *cp, int direction,
- const struct sk_buff *skb,
- struct ip_vs_proto_data *pd);
+ void (*state_transition)(struct ip_vs_conn *cp, int direction,
+ const struct sk_buff *skb,
+ struct ip_vs_proto_data *pd);
int (*register_app)(struct net *net, struct ip_vs_app *inc);
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 4f77bb1..00ea1ad 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -188,14 +188,13 @@ ip_vs_conn_stats(struct ip_vs_conn *cp, struct ip_vs_service *svc)
}
-static inline int
+static inline void
ip_vs_set_state(struct ip_vs_conn *cp, int direction,
const struct sk_buff *skb,
struct ip_vs_proto_data *pd)
{
- if (unlikely(!pd->pp->state_transition))
- return 0;
- return pd->pp->state_transition(cp, direction, skb, pd);
+ if (likely(pd->pp->state_transition))
+ pd->pp->state_transition(cp, direction, skb, pd);
}
static inline int
@@ -557,7 +556,7 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
ip_vs_in_stats(cp, skb);
/* set state */
- cs = ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd);
+ ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd);
/* transmit the first SYN packet */
ret = cp->packet_xmit(skb, cp, pd->pp);
@@ -1490,7 +1489,7 @@ ip_vs_in(unsigned int hooknum, struct sk_buff *skb, int af)
struct ip_vs_protocol *pp;
struct ip_vs_proto_data *pd;
struct ip_vs_conn *cp;
- int ret, restart, pkts;
+ int ret, pkts;
struct netns_ipvs *ipvs;
/* Already marked as IPVS request or reply? */
@@ -1591,7 +1590,7 @@ ip_vs_in(unsigned int hooknum, struct sk_buff *skb, int af)
}
ip_vs_in_stats(cp, skb);
- restart = ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd);
+ ip_vs_set_state(cp, IP_VS_DIR_INPUT, skb, pd);
if (cp->packet_xmit)
ret = cp->packet_xmit(skb, cp, pp);
/* do not touch skb anymore */
diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
index d12ed53..1fbf7a2 100644
--- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
@@ -906,7 +906,7 @@ static const char *sctp_state_name(int state)
return "?";
}
-static inline int
+static inline void
set_sctp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
int direction, const struct sk_buff *skb)
{
@@ -924,7 +924,7 @@ set_sctp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
sch = skb_header_pointer(skb, ihl + sizeof(sctp_sctphdr_t),
sizeof(_sctpch), &_sctpch);
if (sch == NULL)
- return 0;
+ return;
chunk_type = sch->type;
/*
@@ -993,21 +993,15 @@ set_sctp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
cp->timeout = pd->timeout_table[cp->state = next_state];
else /* What to do ? */
cp->timeout = sctp_timeouts[cp->state = next_state];
-
- return 1;
}
-static int
+static void
sctp_state_transition(struct ip_vs_conn *cp, int direction,
const struct sk_buff *skb, struct ip_vs_proto_data *pd)
{
- int ret = 0;
-
spin_lock(&cp->lock);
- ret = set_sctp_state(pd, cp, direction, skb);
+ set_sctp_state(pd, cp, direction, skb);
spin_unlock(&cp->lock);
-
- return ret;
}
static inline __u16 sctp_app_hashkey(__be16 port)
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index c0cc341..ef8641f 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -546,7 +546,7 @@ set_tcp_state(struct ip_vs_proto_data *pd, struct ip_vs_conn *cp,
/*
* Handle state transitions
*/
-static int
+static void
tcp_state_transition(struct ip_vs_conn *cp, int direction,
const struct sk_buff *skb,
struct ip_vs_proto_data *pd)
@@ -561,13 +561,11 @@ tcp_state_transition(struct ip_vs_conn *cp, int direction,
th = skb_header_pointer(skb, ihl, sizeof(_tcph), &_tcph);
if (th == NULL)
- return 0;
+ return;
spin_lock(&cp->lock);
set_tcp_state(pd, cp, direction, th);
spin_unlock(&cp->lock);
-
- return 1;
}
static inline __u16 tcp_app_hashkey(__be16 port)
diff --git a/net/netfilter/ipvs/ip_vs_proto_udp.c b/net/netfilter/ipvs/ip_vs_proto_udp.c
index f1282cb..f4b7262 100644
--- a/net/netfilter/ipvs/ip_vs_proto_udp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_udp.c
@@ -454,18 +454,17 @@ static const char * udp_state_name(int state)
return udp_state_name_table[state] ? udp_state_name_table[state] : "?";
}
-static int
+static void
udp_state_transition(struct ip_vs_conn *cp, int direction,
const struct sk_buff *skb,
struct ip_vs_proto_data *pd)
{
if (unlikely(!pd)) {
pr_err("UDP no ns data\n");
- return 0;
+ return;
}
cp->timeout = pd->timeout_table[IP_VS_UDP_S_NORMAL];
- return 1;
}
static void __udp_init(struct net *net, struct ip_vs_proto_data *pd)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/5] IPVS: Add documentation for new sysctl entries
From: Simon Horman @ 2011-09-26 9:05 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, David S. Miller, Simon Horman
In-Reply-To: <1317027938-22053-1-git-send-email-horms@verge.net.au>
Add missing documentation for conntrack, snat_reroute and sync_version.
Also fix up a typo, IPVS_DEBUG should be IP_VS_DEBUG.
Acked-by: Julian Anastasov <ja@ssi.bg>
Acked-by Hans Schillstrom <hans@schillstrom.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Documentation/networking/ipvs-sysctl.txt | 52 +++++++++++++++++++++++++++++-
1 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index 4ccdbca..1dcdd49 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -15,6 +15,23 @@ amemthresh - INTEGER
enabled and the variable is automatically set to 2, otherwise
the strategy is disabled and the variable is set to 1.
+conntrack - BOOLEAN
+ 0 - disabled (default)
+ not 0 - enabled
+
+ If set, maintain connection tracking entries for
+ connections handled by IPVS.
+
+ This should be enabled if connections handled by IPVS are to be
+ also handled by stateful firewall rules. That is, iptables rules
+ that make use of connection tracking. It is a performance
+ optimisation to disable this setting otherwise.
+
+ Connections handled by the IPVS FTP application module
+ will have connection tracking entries regardless of this setting.
+
+ Only available when IPVS is compiled with the CONFIG_IP_VS_NFCT
+
cache_bypass - BOOLEAN
0 - disabled (default)
not 0 - enabled
@@ -39,7 +56,7 @@ debug_level - INTEGER
11 - IPVS packet handling (ip_vs_in/ip_vs_out)
12 or more - packet traversal
- Only available when IPVS is compiled with the CONFIG_IPVS_DEBUG
+ Only available when IPVS is compiled with the CONFIG_IP_VS_DEBUG
Higher debugging levels include the messages for lower debugging
levels, so setting debug level 2, includes level 0, 1 and 2
@@ -141,3 +158,36 @@ sync_threshold - INTEGER
synchronized, every time the number of its incoming packets
modulus 50 equals the threshold. The range of the threshold is
from 0 to 49.
+
+snat_reroute - BOOLEAN
+ 0 - disabled
+ not 0 - enabled (default)
+
+ If enabled, recalculate the route of SNATed packets from
+ realservers so that they are routed as if they originate from the
+ director. Otherwise they are routed as if they are forwarded by the
+ director.
+
+ If policy routing is in effect then it is possible that the route
+ of a packet originating from a director is routed differently to a
+ packet being forwarded by the director.
+
+ If policy routing is not in effect then the recalculated route will
+ always be the same as the original route so it is an optimisation
+ to disable snat_reroute and avoid the recalculation.
+
+sync_version - INTEGER
+ default 1
+
+ The version of the synchronisation protocol used when sending
+ synchronisation messages.
+
+ 0 selects the original synchronisation protocol (version 0). This
+ should be used when sending synchronisation messages to a legacy
+ system that only understands the original synchronisation protocol.
+
+ 1 selects the current synchronisation protocol (version 1). This
+ should be used where possible.
+
+ Kernels with this sync_version entry are able to receive messages
+ of both version 1 and version 2 of the synchronisation protocol.
--
1.7.5.4
^ permalink raw reply related
* [GIT PULL net-next] IPVS
From: Simon Horman @ 2011-09-26 9:05 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel, netfilter
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy,
Pablo Neira Ayuso, David S. Miller
Hi,
with all the excitement of kernel.org being offline and a bunch of trees
likewise being offline I am a little unsure who should take this pull
request which is based on the current net-next tree. But I guess it should
be Patrick, Pablo or Dave.
The following changes since commit 7777de9af54a1402c79bf7663b38ff5ba308dd45:
qlcnic: Change CDRP function (2011-09-23 14:23:59 -0400)
are available in the git repository at:
git://github.com/horms/ipvs-next.git master
Krzysztof Wilczynski (1):
ipvs: Expose ip_vs_ftp module parameters via sysfs.
Simon Horman (4):
IPVS: Add documentation for new sysctl entries
IPVS: Remove unused parameter from ip_vs_confirm_conntrack()
IPVS: Remove unused return value of protocol state transitions
IPVS: Removed unused variables
Documentation/networking/ipvs-sysctl.txt | 52 +++++++++++++++++++++++++++++-
include/net/ip_vs.h | 11 +++---
net/netfilter/ipvs/ip_vs_core.c | 13 +++----
net/netfilter/ipvs/ip_vs_ctl.c | 4 --
net/netfilter/ipvs/ip_vs_ftp.c | 5 ++-
net/netfilter/ipvs/ip_vs_nfct.c | 2 +-
net/netfilter/ipvs/ip_vs_proto_sctp.c | 14 ++------
net/netfilter/ipvs/ip_vs_proto_tcp.c | 6 +--
net/netfilter/ipvs/ip_vs_proto_udp.c | 5 +--
net/netfilter/ipvs/ip_vs_xmit.c | 2 +-
10 files changed, 75 insertions(+), 39 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] net: Disable false positive memory leak report
From: Huajun Li @ 2011-09-26 8:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Huajun Li
In-Reply-To: <1317014958.2853.0.camel@edumazet-laptop>
Eric, thanks for your response. :)
2011/9/26 Eric Dumazet <eric.dumazet@gmail.com>:
> Le samedi 24 septembre 2011 à 23:57 +0800, Huajun Li a écrit :
>> Memory leak detector reports following false positive memory leak, the
>> patch disables it.
>>
>> unreferenced object 0xffff880073a70000 (size 8192):
>> comm "swapper", pid 1, jiffies 4294937832 (age 445.740s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<ffffffff8124db64>] create_object+0x144/0x360
>> [<ffffffff8191192e>] kmemleak_alloc+0x7e/0x110
>> [<ffffffff81235b26>] __kmalloc_node+0x156/0x3a0
>> [<ffffffff81935512>] flow_cache_cpu_prepare.clone.1+0x58/0xc0
>> [<ffffffff8214c361>] flow_cache_init_global+0xb6/0x1af
>> [<ffffffff8100225d>] do_one_initcall+0x4d/0x260
>> [<ffffffff820ec2e9>] kernel_init+0x161/0x23a
>> [<ffffffff8194ab04>] kernel_thread_helper+0x4/0x10
>> [<ffffffffffffffff>] 0xffffffffffffffff
>> unreferenced object 0xffff880073a74290 (size 8192):
>> comm "swapper", pid 1, jiffies 4294937832 (age 445.740s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<ffffffff8124db64>] create_object+0x144/0x360
>> [<ffffffff8191192e>] kmemleak_alloc+0x7e/0x110
>> [<ffffffff81235b26>] __kmalloc_node+0x156/0x3a0
>> [<ffffffff81935512>] flow_cache_cpu_prepare.clone.1+0x58/0xc0
>> [<ffffffff8214c361>] flow_cache_init_global+0xb6/0x1af
>> [<ffffffff8100225d>] do_one_initcall+0x4d/0x260
>> [<ffffffff820ec2e9>] kernel_init+0x161/0x23a
>> [<ffffffff8194ab04>] kernel_thread_helper+0x4/0x10
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>>
>> Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
>> ---
>> net/core/flow.c | 7 +++++++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/core/flow.c b/net/core/flow.c
>> index 555a456..ba3e617 100644
>> --- a/net/core/flow.c
>> +++ b/net/core/flow.c
>> @@ -365,6 +365,13 @@ static int __cpuinit
>> flow_cache_cpu_prepare(struct flow_cache *fc, int cpu)
>>
>> if (!fcp->hash_table) {
>> fcp->hash_table = kzalloc_node(sz, GFP_KERNEL, cpu_to_node(cpu));
>> + /*
>> + * Avoid a kmemleak false positive. The pointer to this block
>> + * is refferenced by per-CPU varaible, here just mark it as not
>> + * being a leak.
>> + */
>> + kmemleak_not_leak(fcp->hash_table);
>> +
>> if (!fcp->hash_table) {
>> pr_err("NET: failed to allocate flow cache sz %zu\n", sz);
>> return -ENOMEM;
>
> This makes no sense to me.
>
> per-cpu variables are taken into account by kmemleak.
>
Yes, I think so.
> If not, you should report this problem to kmemleak maintainer.
>
To deal with false positives/negatives, in kmemleak document, it says:
...
The false positives are objects wrongly reported as being memory leaks
(orphan). For objects known not to be leaks, kmemleak provides the
kmemleak_not_leak function. The kmemleak_ignore could also be used if
the memory block is known not to contain other pointers and it will no
longer be scanned.
...
For some scenarios, _maybe_ it's hard for kmemleak to give report
exactly, and I think it is known issue for the maintainers, so hope
there will be a powerful version soon. :)
However, before the new version of kmemleak(if there is new version)
comes, is it possible to disable this false positive report as other
components? You know, other guys maybe also check the code once they
meet the report again just like me.
^ 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