From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753272AbdBGIDq (ORCPT ); Tue, 7 Feb 2017 03:03:46 -0500 Received: from mx2.suse.de ([195.135.220.15]:44395 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753104AbdBGIDp (ORCPT ); Tue, 7 Feb 2017 03:03:45 -0500 Date: Tue, 7 Feb 2017 09:03:43 +0100 From: Michal Hocko To: "Luis R. Rodriguez" Cc: Andrew Morton , Ingo Molnar , Andy Lutomirski , Kees Cook , "Eric W. Biederman" , Mateusz Guzik , "linux-kernel@vger.kernel.org" Subject: Re: kmemleak splat on copy_process() Message-ID: <20170207080343.GA5065@dhcp22.suse.cz> References: <20170206094741.GB3097@dhcp22.suse.cz> <20170207013702.GF24047@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170207013702.GF24047@wotan.suse.de> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 07-02-17 02:37:02, Luis R. Rodriguez wrote: > On Mon, Feb 06, 2017 at 10:47:41AM +0100, Michal Hocko wrote: > > 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: > > > [] kmemleak_alloc+0x4a/0xa0 > > > [] __vmalloc_node_range+0x206/0x2a0 > > > [] copy_process.part.36+0x609/0x1cc0 > > > [] _do_fork+0xd7/0x390 > > > [] SyS_clone+0x19/0x20 > > > [] do_syscall_64+0x5b/0xc0 > > > [] return_from_SYSCALL_64+0x0/0x6a > > > [] 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? > > Although I can reproduce the splat on kmemleak, getting it to trigger > at a point I can stop the kernel and inspect the process seems rather hard. Can you make the kernel BUG_ON in this case and check the vmcore? > > From a quick check I do not see any leak there either. > > Then in that case what about: This just disables the kmemleak altogether which doesn't sound like a good idea to me. > diff --git a/kernel/fork.c b/kernel/fork.c > index 937ba59709c9..3c96aafa1f82 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -196,6 +196,7 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) > PAGE_KERNEL, > 0, node, __builtin_return_address(0)); > > + kmemleak_ignore(stack); > /* > * We can't call find_vm_area() in interrupt context, and > * free_thread_stack() can be called in interrupt context, > > I no longer get the spurious splats from kmemleak after this. > > Luis -- Michal Hocko SUSE Labs