Hi,
> You may want to disable the kmemleak testing to reduce the amount of
> leaks reported.
The kmemleak results in MIPS that I have included in the previous mail
were obtained during the booting of the malta kernel.
Later, I have checked the "real" usage by using the default
"kmemleak_test" module.
Following output shows the kmemleak results when I used the "kmemleak_test.ko"
debian-mips:~# cat /sys/kernel/debug/kmemleak
........
unreferenced object 0xc0064000 (size 64):
comm "insmod", pid 4233, jiffies 430046 (age 175.970s)
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:
[<801b1b58>] __vmalloc_node_range+0x16c/0x1e0
[<801b1bfc>] __vmalloc_node+0x30/0x3c
[<801b1d94>] vmalloc+0x2c/0x38
[<c005b168>] 0xc005b168
[<80100584>] do_one_initcall+0x174/0x1e0
[<8016b4bc>] sys_init_module+0x1b8/0x153c
[<8010bf30>] stack_done+0x20/0x40
unreferenced object 0xc0067000 (size 64):
comm "insmod", pid 4233, jiffies 430046 (age 175.970s)
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:
[<801b1b58>] __vmalloc_node_range+0x16c/0x1e0
[<801b1bfc>] __vmalloc_node+0x30/0x3c
[<801b1d94>] vmalloc+0x2c/0x38
[<c005b17c>] 0xc005b17c
[<80100584>] do_one_initcall+0x174/0x1e0
[<8016b4bc>] sys_init_module+0x1b8/0x153c
[<8010bf30>] stack_done+0x20/0x40
unreferenced object 0xc006a000 (size 64):
comm "insmod", pid 4233, jiffies 430046 (age 175.970s)
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:
[<801b1b58>] __vmalloc_node_range+0x16c/0x1e0
[<801b1bfc>] __vmalloc_node+0x30/0x3c
[<801b1d94>] vmalloc+0x2c/0x38
[<c005b190>] 0xc005b190
[<80100584>] do_one_initcall+0x174/0x1e0
[<8016b4bc>] sys_init_module+0x1b8/0x153c
[<8010bf30>] stack_done+0x20/0x40
debian-mips:~# lsmod
Module Size Used by
kmemleak_test 867 0
debian-mips:~# rmmod kmemleak_test
debian-mips:~#
> These are probably false positives.
The previous results could be false positives. However, the current
results are not false positives as we have intentionally created the
memory leaks using the test module.
> Since the pointer referring this
> block (udp_table) is __read_mostly, is it possible that the
> corresponding section gets placed outside the _sdata.._edata range?
I am not sure about this. Please let know how can I check this.
Warm Regards,
Maxin B. John
On Tue, Mar 29, 2011 at 11:40 AM, Catalin Marinas
<catalin.marinas@xxxxxxx> wrote:
> On Mon, 2011-03-28 at 22:15 +0100, Maxin John wrote:
>> > Just add "depends on MIPS" and give it a try.
>> As per your suggestion, I have tried it in my qemu environment (MIPS malta).
>>
>> With a minor modification in arch/mips/kernel/vmlinux.lds.S (added the
>> symbol _sdata ), I was able to add kmemleak support for MIPS.
>>
>> Output in MIPS (Malta):
>
> You may want to disable the kmemleak testing to reduce the amount of
> leaks reported.
>
>> debian-mips:~# uname -a
>> Linux debian-mips 2.6.38-08826-g1788c20-dirty #4 SMP Mon Mar 28
>> 23:22:04 EEST 2011 mips GNU/Linux
>> debian-mips:~# mount -t debugfs nodev /sys/kernel/debug/
>> debian-mips:~# cat /sys/kernel/debug/kmemleak
>> unreferenced object 0x8f95d000 (size 4096):
>> comm "swapper", pid 1, jiffies 4294937330 (age 467.240s)
>> 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:
>> [<80529644>] alloc_large_system_hash+0x2f8/0x410
>> [<8053864c>] udp_table_init+0x4c/0x158
>> [<80538774>] udp_init+0x1c/0x94
>> [<80538b34>] inet_init+0x184/0x2a0
>> [<80100584>] do_one_initcall+0x174/0x1e0
>> [<8051f348>] kernel_init+0xe4/0x174
>> [<80103d4c>] kernel_thread_helper+0x10/0x18
>> unreferenced object 0x8f95e000 (size 4096):
>> comm "swapper", pid 1, jiffies 4294937330 (age 467.240s)
>> 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:
>> [<80529644>] alloc_large_system_hash+0x2f8/0x410
>> [<8053864c>] udp_table_init+0x4c/0x158
>> [<8053881c>] udplite4_register+0x24/0xa8
>> [<80538b3c>] inet_init+0x18c/0x2a0
>> [<80100584>] do_one_initcall+0x174/0x1e0
>> [<8051f348>] kernel_init+0xe4/0x174
>> [<80103d4c>] kernel_thread_helper+0x10/0x18
>
> These are probably false positives. Since the pointer referring this
> block (udp_table) is __read_mostly, is it possible that the
> corresponding section gets placed outside the _sdata.._edata range?
>
> diff --git a/arch/mips/include/asm/cache.h b/arch/mips/include/asm/cache.h
> index 650ac9b..b4db69f 100644
> --- a/arch/mips/include/asm/cache.h
> +++ b/arch/mips/include/asm/cache.h
> @@ -17,6 +17,6 @@
> #define SMP_CACHE_SHIFT L1_CACHE_SHIFT
> #define SMP_CACHE_BYTES L1_CACHE_BYTES
>
> -#define __read_mostly __attribute__((__section__(".data.read_mostly")))
> +#define __read_mostly __attribute__((__section__(".data..read_mostly")))
>
> #endif /* _ASM_CACHE_H */
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 570607b..6f6d5d0 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -74,6 +74,7 @@ SECTIONS
> INIT_TASK_DATA(PAGE_SIZE)
> NOSAVE_DATA
> CACHELINE_ALIGNED_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
> + READ_MOSTLY_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
> DATA_DATA
> CONSTRUCTORS
> }
>
>> unreferenced object 0x8f072000 (size 4096):
>> comm "swapper", pid 1, jiffies 4294937680 (age 463.840s)
>> 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:
>> [<801ba3d8>] __kmalloc+0x130/0x180
>> [<805461bc>] flow_cache_cpu_prepare+0x50/0xa8
>> [<8053746c>] flow_cache_init_global+0x90/0x138
>> [<80100584>] do_one_initcall+0x174/0x1e0
>> [<8051f348>] kernel_init+0xe4/0x174
>> [<80103d4c>] kernel_thread_helper+0x10/0x18
>
> Same here, flow_cachep pointer is __read_mostly.
>
> --
> Catalin
>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx 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