> https://bugzilla.kernel.org/show_bug.cgi?id=27552 >--- Comment #1 from Greg Kroah-Hartman <greg@xxxxxxxxx> 2011-01-25 05:49:40 --- On Tue, Jan 25, 2011 at 04:16:51AM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: >> Kernel Version: 2.6.34.1 >That is an old and unsupported version of the kernel. Can you try something newer? I will see if I can get something fresher installed later today. >> I am using the g_serial USB CDC gadget in an ARM embedded system, and >> have noticed that a small amount of memory is leaked whenever >> /dev/ttyGS0 is opened and closed. >> >> Try: >> >> while true ; do echo 1 > /dev/ttyGS0; cls; free; done >> >> On my board, this eats up memory at several MB/s. If kmemleak is >> built, /proc/slabinfo shows an increasing number of kmemleak_object's. >What does kmemleak say is causing the leak? Kmemleak reports a couple of leaks on this board, but I think they are unrelated to the huge accumulation of kobjects that I get when opening and closing the gadget. I assume that means they are actually referenced, but I am not too clear on how kmemleak works. Here is the output: unreferenced object 0xc3d1e000 (size 5120): comm "swapper", pid 1, jiffies 4294937389 (age 702.360s) hex dump (first 32 bytes): 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 3.3.3.3.3.3.3.3. 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 3.3.3.3.3.3.3.3. backtrace: [<c0011254>] alloc_large_system_hash+0x198/0x240 [<c001c0e4>] udp_table_init+0x48/0x174 [<c001c224>] udp_init+0x14/0x94 [<c001c81c>] inet_init+0xf0/0x1d4 [<c002b334>] do_one_initcall+0x5c/0x1c4 [<c0008400>] kernel_init+0x94/0x148 [<c002ce18>] kernel_thread_exit+0x0/0x8 [<ffffffff>] 0xffffffff unreferenced object 0xc3d38000 (size 5120): comm "swapper", pid 1, jiffies 4294937389 (age 702.360s) hex dump (first 32 bytes): 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 3.3.3.3.3.3.3.3. 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 33 cc 3.3.3.3.3.3.3.3. backtrace: [<c0011254>] alloc_large_system_hash+0x198/0x240 [<c001c0e4>] udp_table_init+0x48/0x174 [<c001c2d0>] udplite4_register+0x14/0xa4 [<c001c820>] inet_init+0xf4/0x1d4 [<c002b334>] do_one_initcall+0x5c/0x1c4 [<c0008400>] kernel_init+0x94/0x148 [<c002ce18>] kernel_thread_exit+0x0/0x8 [<ffffffff>] 0xffffffff unreferenced object 0xc3dbd6a0 (size 192): comm "swapper", pid 1, jiffies 4294937465 (age 701.610s) hex dump (first 32 bytes): db ce ec c3 00 00 00 00 00 00 02 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 ................ backtrace: [<c00988f4>] __kmalloc_track_caller+0x168/0x1b0 [<c008657c>] kmemdup+0x1c/0x38 [<c014965c>] parse_cmdline_partitions+0x23c/0x288 [<c0148928>] parse_mtd_partitions+0x78/0xc8 [<c0016df8>] atmel_nand_probe+0x294/0x3a4 [<c01419c4>] platform_drv_probe+0x1c/0x24 [<c0140a34>] driver_probe_device+0xac/0x184 [<c0140b6c>] __driver_attach+0x60/0x84 [<c0140288>] bus_for_each_dev+0x4c/0x8c [<c013fb74>] bus_add_driver+0xa0/0x220 [<c0140e78>] driver_register+0xc0/0x150 [<c0141e0c>] platform_driver_probe+0x18/0x90 [<c002b334>] do_one_initcall+0x5c/0x1c4 [<c0008400>] kernel_init+0x94/0x148 [<c002ce18>] kernel_thread_exit+0x0/0x8 [<ffffffff>] 0xffffffff And here is the slabinfo: # cat /proc/slabinfo | grep kmemleak_object kmemleak_object 82502 82535 224 17 1 : tunables 32 16 0 : slabdata 4855 4855 0 : globalstat 112553 82534 5228 1 0 1 0 0 0 : cpustat 117917 11923 45497 1862 # while true; do echo '1' > /dev/ttyGS0; done <interrupted after 4 seconds> # cat /proc/slabinfo | grep kmemleak_object kmemleak_object 128709 128758 224 17 1 : tunables 32 16 0 : slabdata 7574 7574 0 : globalstat 158989 128757 7952 1 0 1 0 0 0 : cpustat 163970 17380 50777 1875 >Also, can you post this to the linux-usb@xxxxxxxxxxxxxxx mailing list so we can discuss it there instead of in bugzilla? That way is much faster and easier. Done. James L. ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±þë)íè jg¬±¨ ¶‰šŽŠÝjÿ¾«þG«é¸ ¢·¦j:+v‰¨Šwèm¶Ÿÿþø®w¥þŠà£¢·hšâÿ†Ù
