@@ -366,7 +366,11 @@ int sctp_sysctl_net_register(struct net *net)voidsctp_sysctl_net_unregister(structnet*net){+structctl_table*table;++table=net->sctp.sysctl_hdr->ctl_table_arg;unregister_net_sysctl_table(net->sctp.sysctl_header);+kfree(table);}staticstructctl_table_header*sctp_sysctl_header;
@@ -366,7 +366,11 @@ int sctp_sysctl_net_register(struct net *net)voidsctp_sysctl_net_unregister(structnet*net){+structctl_table*table;++table=net->sctp.sysctl_hdr->ctl_table_arg;unregister_net_sysctl_table(net->sctp.sysctl_header);+kfree(table);}staticstructctl_table_header*sctp_sysctl_header;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -366,7 +366,11 @@ int sctp_sysctl_net_register(struct net *net)voidsctp_sysctl_net_unregister(structnet*net){+structctl_table*table;++table=net->sctp.sysctl_hdr->ctl_table_arg;unregister_net_sysctl_table(net->sctp.sysctl_header);+kfree(table);}staticstructctl_table_header*sctp_sysctl_header;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: "Eric W. Biederman" <redacted>
Doh. I should have known better.
Eric
@@ -366,7 +366,11 @@ int sctp_sysctl_net_register(struct net *net) void sctp_sysctl_net_unregister(struct net *net) {+ struct ctl_table *table;++ table = net->sctp.sysctl_hdr->ctl_table_arg; unregister_net_sysctl_table(net->sctp.sysctl_header);+ kfree(table); }
In what tree does this compile? I tried both 'net' and 'net-next'
and got the same exact result:
net/sctp/sysctl.c: In function ‘sctp_sysctl_net_unregister’:
net/sctp/sysctl.c:371:19: error: ‘struct netns_sctp’ has no member named ‘sysctl_hdr’
make[1]: *** [net/sctp/sysctl.o] Error 1
make: *** [net/sctp/sysctl.o] Error 2
@@ -366,7 +366,11 @@ int sctp_sysctl_net_register(struct net *net)voidsctp_sysctl_net_unregister(structnet*net){+structctl_table*table;++table=net->sctp.sysctl_hdr->ctl_table_arg;unregister_net_sysctl_table(net->sctp.sysctl_header);+kfree(table);}staticstructctl_table_header*sctp_sysctl_header;
@@ -366,7 +366,11 @@ int sctp_sysctl_net_register(struct net *net)voidsctp_sysctl_net_unregister(structnet*net){+structctl_table*table;++table=net->sctp.sysctl_header->ctl_table_arg;unregister_net_sysctl_table(net->sctp.sysctl_header);+kfree(table);}staticstructctl_table_header*sctp_sysctl_header;
From: Martin Mokrejs <hidden> Date: 2013-01-28 08:33:31
David Miller wrote:
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Sun, 27 Jan 2013 19:25:11 -0800
quoted
The typo is fixed in the patch this time in addition to my test
tree.
Applied, thanks for fixing this up Eric.
I did check now how come that I patched my 3.7.4 on Jan 24. Looks like
-head or -next has different namings. For me, the original patch applied
fine. So far I haven't hit the memleak although it happened only once to me
before the patch. But probably I can confirm say Tested-by:.
#
-rw-r--r-- 1 root root 8435 Jan 24 17:12 /usr/src/linux-3.7.4/net/sctp/sysctl.c
-rw-rw-r-- 1 root root 8347 Jan 21 20:45 /usr/src/linux-3.7.4/net/sctp/sysctl.c.orig
# ls -la /usr/src/linux-3.7.4/net/sctp/sysctl.o
-rw-r--r-- 1 root root 246144 Jan 21 22:37 /usr/src/linux-3.7.4/net/sctp/sysctl.o
# ls -la /usr/src/linux-3.7.4/arch/x86/boot/bzImage
-rw-r--r-- 1 root root 3794592 Jan 21 22:45 /usr/src/linux-3.7.4/arch/x86/boot/bzImage
#
If 3.7 and earlier need the old patch (like I currently think) please make them aware
of that.
Martin
From: Eric W. Biederman <hidden> Date: 2013-01-28 15:47:26
Martin Mokrejs [off-list ref] writes:
David Miller wrote:
quoted
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Sun, 27 Jan 2013 19:25:11 -0800
quoted
The typo is fixed in the patch this time in addition to my test
tree.
Applied, thanks for fixing this up Eric.
I did check now how come that I patched my 3.7.4 on Jan 24. Looks like
-head or -next has different namings. For me, the original patch applied
fine. So far I haven't hit the memleak although it happened only once to me
before the patch.
The problem isn't that the patch doesn't apply the problem is that the
patch did not build. The naming has not changed in the git history.
But probably I can confirm say Tested-by:.
#
-rw-r--r-- 1 root root 8435 Jan 24 17:12 /usr/src/linux-3.7.4/net/sctp/sysctl.c
-rw-rw-r-- 1 root root 8347 Jan 21 20:45 /usr/src/linux-3.7.4/net/sctp/sysctl.c.orig
# ls -la /usr/src/linux-3.7.4/net/sctp/sysctl.o
-rw-r--r-- 1 root root 246144 Jan 21 22:37 /usr/src/linux-3.7.4/net/sctp/sysctl.o
# ls -la /usr/src/linux-3.7.4/arch/x86/boot/bzImage
-rw-r--r-- 1 root root 3794592 Jan 21 22:45 /usr/src/linux-3.7.4/arch/x86/boot/bzImage
#
It doesn't look look like you rebuilt anything after you applied the
changes to net/sctp/sysctl.c. sysctl.o and bzImage are both 3 days older.
Eric
From: Martin Mokrejs <hidden> Date: 2013-01-28 21:17:12
Hi Eric,
Eric W. Biederman wrote:
Martin Mokrejs [off-list ref] writes:
quoted
David Miller wrote:
quoted
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Sun, 27 Jan 2013 19:25:11 -0800
quoted
The typo is fixed in the patch this time in addition to my test
tree.
Applied, thanks for fixing this up Eric.
I did check now how come that I patched my 3.7.4 on Jan 24. Looks like
-head or -next has different namings. For me, the original patch applied
fine. So far I haven't hit the memleak although it happened only once to me
before the patch.
The problem isn't that the patch doesn't apply the problem is that the
patch did not build. The naming has not changed in the git history.
quoted
But probably I can confirm say Tested-by:.
#
-rw-r--r-- 1 root root 8435 Jan 24 17:12 /usr/src/linux-3.7.4/net/sctp/sysctl.c
-rw-rw-r-- 1 root root 8347 Jan 21 20:45 /usr/src/linux-3.7.4/net/sctp/sysctl.c.orig
# ls -la /usr/src/linux-3.7.4/net/sctp/sysctl.o
-rw-r--r-- 1 root root 246144 Jan 21 22:37 /usr/src/linux-3.7.4/net/sctp/sysctl.o
# ls -la /usr/src/linux-3.7.4/arch/x86/boot/bzImage
-rw-r--r-- 1 root root 3794592 Jan 21 22:45 /usr/src/linux-3.7.4/arch/x86/boot/bzImage
#
It doesn't look look like you rebuilt anything after you applied the
changes to net/sctp/sysctl.c. sysctl.o and bzImage are both 3 days older.
Ah, I must have been really blind. Thanks for pointing that out. I should
really start to do:
make bzImage && make modules && make modules_install && cp arch/x86_64/boot/bzImage /boot/vmlinuz-$ver
echo "silly me, make(1) did not delete the old bzImage"
So I haven't tested the patch yet. doh. Provided I am running 3 days without reproducing
the original memleak on an unpatched kernel I doubt I can easily prove it after a reboot.
:( Will probably stay untested. But compiles fine here. ;-)
Thanks,
Martin
From: Martin Mokrejs <hidden> Date: 2013-01-28 21:25:39
Martin Mokrejs wrote:
Hi Eric,
Eric W. Biederman wrote:
quoted
Martin Mokrejs [off-list ref] writes:
quoted
David Miller wrote:
quoted
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Sun, 27 Jan 2013 19:25:11 -0800
quoted
The typo is fixed in the patch this time in addition to my test
tree.
Applied, thanks for fixing this up Eric.
So I haven't tested the patch yet. doh. Provided I am running 3 days without reproducing
the original memleak on an unpatched kernel I doubt I can easily prove it after a reboot.
Umm, I spoke too early. It did happen again during these 3 days on unpatched 3.7.4:
unreferenced object 0xffff880402769030 (size 2048):
comm "chrome_sandbox", pid 4720, jiffies 4294966701 (age 285697.590s)
hex dump (first 32 bytes):
b2 68 89 81 ff ff ff ff 20 84 4f d8 03 88 ff ff .h...... .O.....
04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff815b4aad>] kmemleak_alloc+0x21/0x3e
[<ffffffff81110352>] slab_post_alloc_hook+0x28/0x2a
[<ffffffff81113fad>] __kmalloc_track_caller+0xf1/0x104
[<ffffffff810f10c2>] kmemdup+0x1b/0x30
[<ffffffff81571e9f>] sctp_sysctl_net_register+0x1f/0x72
[<ffffffff8155d305>] sctp_net_init+0x100/0x39f
[<ffffffff814ad53c>] ops_init+0xc6/0xf5
[<ffffffff814ad5b7>] setup_net+0x4c/0xd0
[<ffffffff814ada5e>] copy_net_ns+0x6d/0xd6
[<ffffffff810938b1>] create_new_namespaces+0xd7/0x147
[<ffffffff810939f4>] copy_namespaces+0x63/0x99
[<ffffffff81076733>] copy_process+0xa65/0x1233
[<ffffffff81077030>] do_fork+0x10b/0x271
[<ffffffff8100a0e9>] sys_clone+0x23/0x25
[<ffffffff815dda73>] stub_clone+0x13/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
But I won't make it to a reboot in next 2-3 days to test the patch v2, sorry.
Martin
From: Eric W. Biederman <hidden> Date: 2013-01-29 00:21:15
Martin Mokrejs [off-list ref] writes:
Martin Mokrejs wrote:
quoted
Hi Eric,
Eric W. Biederman wrote:
quoted
Martin Mokrejs [off-list ref] writes:
quoted
David Miller wrote:
quoted
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Sun, 27 Jan 2013 19:25:11 -0800
quoted
The typo is fixed in the patch this time in addition to my test
tree.
Applied, thanks for fixing this up Eric.
quoted
So I haven't tested the patch yet. doh. Provided I am running 3 days without reproducing
the original memleak on an unpatched kernel I doubt I can easily prove it after a reboot.
Umm, I spoke too early. It did happen again during these 3 days on unpatched 3.7.4:
unreferenced object 0xffff880402769030 (size 2048):
comm "chrome_sandbox", pid 4720, jiffies 4294966701 (age 285697.590s)
hex dump (first 32 bytes):
b2 68 89 81 ff ff ff ff 20 84 4f d8 03 88 ff ff .h...... .O.....
04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff815b4aad>] kmemleak_alloc+0x21/0x3e
[<ffffffff81110352>] slab_post_alloc_hook+0x28/0x2a
[<ffffffff81113fad>] __kmalloc_track_caller+0xf1/0x104
[<ffffffff810f10c2>] kmemdup+0x1b/0x30
[<ffffffff81571e9f>] sctp_sysctl_net_register+0x1f/0x72
[<ffffffff8155d305>] sctp_net_init+0x100/0x39f
[<ffffffff814ad53c>] ops_init+0xc6/0xf5
[<ffffffff814ad5b7>] setup_net+0x4c/0xd0
[<ffffffff814ada5e>] copy_net_ns+0x6d/0xd6
[<ffffffff810938b1>] create_new_namespaces+0xd7/0x147
[<ffffffff810939f4>] copy_namespaces+0x63/0x99
[<ffffffff81076733>] copy_process+0xa65/0x1233
[<ffffffff81077030>] do_fork+0x10b/0x271
[<ffffffff8100a0e9>] sys_clone+0x23/0x25
[<ffffffff815dda73>] stub_clone+0x13/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
But I won't make it to a reboot in next 2-3 days to test the patch v2, sorry.
No biggy the logic remains the same and the fix in the patch is clrearly
needed from an inspection of the code.
Eric
From: Martin Mokrejs <hidden> Date: 2013-03-05 09:05:15
Hi,
this is to let you know that this patch is still not in stable.
I just fetched 3.7.10 and reproduced the original problem.
I bet this slipped through because there was an initial patch from Vlad Yasevich
on Jan 24, then a follow-up patch from Eric Biedermann which did not compile and
finally a v2 patch from E. B which did compile.
For me the last, v2 patch applies (with some hunk) to 3.7.10 and compiles
fine.
Thanks,
martin
Eric W. Biederman wrote:
quoted hunk
From: Vlad Yasevich <redacted>
Date: Thu, 24 Jan 2013 11:02:47 -0500
Per-net sysctl table needs to be explicitly freed at
net exit. Otherwise we see the following with kmemleak:
unreferenced object 0xffff880402d08000 (size 2048):
comm "chrome_sandbox", pid 18437, jiffies 4310887172 (age 9097.630s)
hex dump (first 32 bytes):
b2 68 89 81 ff ff ff ff 20 04 04 f8 01 88 ff ff .h...... .......
04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff815b4aad>] kmemleak_alloc+0x21/0x3e
[<ffffffff81110352>] slab_post_alloc_hook+0x28/0x2a
[<ffffffff81113fad>] __kmalloc_track_caller+0xf1/0x104
[<ffffffff810f10c2>] kmemdup+0x1b/0x30
[<ffffffff81571e9f>] sctp_sysctl_net_register+0x1f/0x72
[<ffffffff8155d305>] sctp_net_init+0x100/0x39f
[<ffffffff814ad53c>] ops_init+0xc6/0xf5
[<ffffffff814ad5b7>] setup_net+0x4c/0xd0
[<ffffffff814ada5e>] copy_net_ns+0x6d/0xd6
[<ffffffff810938b1>] create_new_namespaces+0xd7/0x147
[<ffffffff810939f4>] copy_namespaces+0x63/0x99
[<ffffffff81076733>] copy_process+0xa65/0x1233
[<ffffffff81077030>] do_fork+0x10b/0x271
[<ffffffff8100a0e9>] sys_clone+0x23/0x25
[<ffffffff815dda73>] stub_clone+0x13/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
I fixed the spelling of sysctl_header so the code actually
compiles. -- EWB.
Reported-by: Martin Mokrejs <redacted>
Signed-off-by: Vlad Yasevich <redacted>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: "Eric W. Biederman" <redacted>
---
The typo is fixed in the patch this time in addition to my test
tree.
net/sctp/sysctl.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
@@ -366,7 +366,11 @@ int sctp_sysctl_net_register(struct net *net)voidsctp_sysctl_net_unregister(structnet*net){+structctl_table*table;++table=net->sctp.sysctl_header->ctl_table_arg;unregister_net_sysctl_table(net->sctp.sysctl_header);+kfree(table);}staticstructctl_table_header*sctp_sysctl_header;
From: Martin Mokrejs <hidden> Date: 2013-03-05 21:04:12
David Miller wrote:
From: Martin Mokrejs <redacted>
Date: Tue, 05 Mar 2013 10:05:06 +0100
quoted
this is to let you know that this patch is still not in stable.
I just fetched 3.7.10 and reproduced the original problem.
3.7.x is end of life and no longer being actively maintained.
??? 3.7.10 was released on 2013-02-27.
I disagree with making a kernel line 3.7 released on 2012-12-11 unsupported
while 3.8.0 was released just on 2013-02-18. That is way too new. Sorry
to say that but I don't expect 3.8 to be tested properly like 3.7.4 was
NOT in January 2013 when I reported the particular sctp bug, and several
others in USB, pci/e hotplug, etc. Now, with 3.8.2 being out one day
already I will hit for sure other bugs. I really want something stable.
For USB3.0 I need 3.2.x at least, actually 3.5 for some better URB handling
... The already buggy (in 3.2.x PCI/e hotplug) got reworked in about 3.5
into another buggy behavior so another workaround had to be invented.
Of course I do appreciate your work but if somebody bothered to report a bug
and some devs bothered to provide patches, you should let the fix go into life.
It is waiting in the patchwork since 1,5 month. By that time, 3.7.x was the
current, latest&greatest stable. I just don't agree.
Sorry for such a rant, I couldn't resist. ;)
Martin