kmemleak splat on copy_process()

[Luis R. Rodriguez]

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