Messages in this thread | | | From | "Luis R. Rodriguez" <> | Date | Fri, 3 Feb 2017 13:06:04 -0800 | Subject | kmemleak splat on copy_process() |
| |
On next-20170125 running some kselftest not yet upstream I eventually get a kmemleak splat:
unreferenced object 0xffffa7b1034b4000 (size 16384): comm "driver_data.sh", pid 6506, jiffies 4295068366 (age 1697.272s) hex dump (first 32 bytes): 9d 6e ac 57 00 00 00 00 74 2d 64 72 69 76 65 72 .n.W....t-driver 5f 64 61 74 61 2e 62 69 6e 0a 00 00 00 00 00 00 _data.bin....... backtrace: [<ffffffff9005f7fa>] kmemleak_alloc+0x4a/0xa0 [<ffffffff8fbe7006>] __vmalloc_node_range+0x206/0x2a0 [<ffffffff8fa7f3e9>] copy_process.part.36+0x609/0x1cc0 [<ffffffff8fa80c77>] _do_fork+0xd7/0x390 [<ffffffff8fa80fd9>] SyS_clone+0x19/0x20 [<ffffffff8fa03b4b>] do_syscall_64+0x5b/0xc0 [<ffffffff9006b3af>] return_from_SYSCALL_64+0x0/0x6a [<ffffffffffffffff>] 0xffffffffffffffff
As per gdb:
(gdb) l *(copy_process+0x609) 0xffffffff8107f3e9 is in copy_process (kernel/fork.c:204). warning: Source file is more recent than executable. 199 /* 200 * We can't call find_vm_area() in interrupt context, and 201 * free_thread_stack() can be called in interrupt context, 202 * so cache the vm_struct. 203 */ 204 if (stack) { 205 tsk->stack_vm_area = find_vm_area(stack); 206 } 207 return stack; 208 #else
So it would seem a complaint about alloc_thread_stack_node() -- I checked but I cannot find the leak so am thinking this is a false positive. Can you confirm?
Luis
| |