On Fri, Feb 18, 2011 at 9:42 AM, Yinglin Luan <[email protected]> wrote: > > On Fri, Feb 18, 2011 at 10:14 PM, Steve Chen <[email protected]> wrote: >> >> On Fri, Feb 18, 2011 at 4:44 AM, Yinglin Luan <[email protected]> wrote: >> > Hi, everyone >> > >> > I notice that the amount of free memory on my dm365 evm gets smaller and >> > smaller, so I enable CONFIG_DEBUG_KMEMLEAK in "Kernel hacking".When I do >> > 'cat /sys/kernel/debug/kmemleak', I get an output: >> > >> > unreferenced object 0xc12920c0 (size 192): >> > comm "softirq", pid 0, jiffies 126399 >> > 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 20 a4 c2 00 00 00 00 ......... ...... >> > backtrace: >> > [<c00ab5d8>] __save_stack_trace+0x34/0x40 >> > [<c00ab6e8>] create_object+0x104/0x1fc >> > [<c0326a90>] kmemleak_alloc+0x40/0x84 >> > [<c00a891c>] kmem_cache_alloc+0xf4/0x10c >> > [<c028b028>] __alloc_skb+0x34/0x108 >> > [<c028bc7c>] dev_alloc_skb+0x20/0x44 >> > [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8 >> > [<c02047e8>] emac_poll+0x244/0x5d0 >> > [<c0292af4>] net_rx_action+0xb4/0x274 >> > [<c004f648>] __do_softirq+0xb0/0x164 >> > [<c004f75c>] irq_exit+0x60/0xb8 >> > [<c0035074>] asm_do_IRQ+0x74/0x8c >> > [<c0035ad8>] __irq_svc+0x58/0xa4 >> > [<c0036fac>] cpu_idle+0x80/0xf0 >> > [<c0326478>] rest_init+0x70/0x84 >> > [<c00089dc>] start_kernel+0x28c/0x2e4 >> > unreferenced object 0xc2c34000 (size 2048): >> > comm "softirq", pid 0, jiffies 126399 >> > hex dump (first 32 bytes): >> > 00 00 00 00 4c 37 f5 2b 6a 6a 19 63 98 82 08 00 ....L7.+jj.c.... >> > 45 00 05 dc fd 34 20 b9 40 11 d2 a2 c0 a8 01 c8 E....4 .@....... >> > backtrace: >> > [<c00ab5d8>] __save_stack_trace+0x34/0x40 >> > [<c00ab6e8>] create_object+0x104/0x1fc >> > [<c0326a90>] kmemleak_alloc+0x40/0x84 >> > [<c00a8fb0>] __kmalloc_track_caller+0x144/0x15c >> > [<c028b048>] __alloc_skb+0x54/0x108 >> > [<c028bc7c>] dev_alloc_skb+0x20/0x44 >> > [<c02035e4>] emac_net_alloc_rx_buf+0x24/0xa8 >> > [<c02047e8>] emac_poll+0x244/0x5d0 >> > [<c0292af4>] net_rx_action+0xb4/0x274 >> > [<c004f648>] __do_softirq+0xb0/0x164 >> > [<c004f75c>] irq_exit+0x60/0xb8 >> > [<c0035074>] asm_do_IRQ+0x74/0x8c >> > [<c0035ad8>] __irq_svc+0x58/0xa4 >> > [<c0036fac>] cpu_idle+0x80/0xf0 >> > [<c0326478>] rest_init+0x70/0x84 >> > [<c00089dc>] start_kernel+0x28c/0x2e4 >> > ...... >> > (the output is too long and the backtrace is almost the same as above) >> > >> > Is this real kernel memory leaks, or it's only transient? >> >> In general, the Linux kernel tries to cache as much data in memory as >> possible in order to improve performance. Therefore, it is quite >> normal to see decreasing free memory over time. As long as the kernel >> is able to free memory cache when needed, there are no issues. >> >> Regards, >> >> Steve > > Thanks for your reply. Maybe the kernel caches sk_buff, but kmemleak > considers them as unreferenced object. I find that the addresses of the > "unreferenced object" reported by kmemleak always change, if they are real > memory leaks, the addresses should be fixed, am I right?
I have not studied kmemleak, so I don't know the answer. Regards, Steve _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
