From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751530AbdBFJrq (ORCPT <rfc822;w@1wt.eu>);
        Mon, 6 Feb 2017 04:47:46 -0500
Received: from mx2.suse.de ([195.135.220.15]:43683 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751093AbdBFJro (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 6 Feb 2017 04:47:44 -0500
Date: Mon, 6 Feb 2017 10:47:41 +0100
From: Michal Hocko <mhocko@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Mateusz Guzik <mguzik@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: kmemleak splat on copy_process()
Message-ID: <20170206094741.GB3097@dhcp22.suse.cz>
References: <CAB=NE6VZXq3y-3pfouYTBUco2Cq2xqoLZrgDFdVx+_=_=SwG_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB=NE6VZXq3y-3pfouYTBUco2Cq2xqoLZrgDFdVx+_=_=SwG_Q@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri 03-02-17 13:06:04, Luis R. Rodriguez wrote:
> 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

Could you check the state of the above process (pid 6506)? Does it still
own its stack? From a quick check I do not see any leak there either.
-- 
Michal Hocko
SUSE Labs