Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752085AbdDCHYY (ORCPT ); Mon, 3 Apr 2017 03:24:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:51801 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751792AbdDCHYW (ORCPT ); Mon, 3 Apr 2017 03:24:22 -0400 Date: Mon, 3 Apr 2017 09:24:02 +0200 From: Michal Hocko To: Joel Fernandes Cc: Vaneet Narang , Miroslav Benes , Maninder Singh , "jeyu@redhat.com" , "rusty@rustcorp.com.au" , "akpm@linux-foundation.org" , "chris@chris-wilson.co.uk" , "aryabinin@virtuozzo.com" , "joonas.lahtinen@linux.intel.com" , "keescook@chromium.org" , "pavel@ucw.cz" , "jinb.park7@gmail.com" , "anisse@astier.eu" , "rafael.j.wysocki@intel.com" , "zijun_hu@htc.com" , "mingo@kernel.org" , "mawilcox@microsoft.com" , "thgarnie@google.com" , "kirill.shutemov@linux.intel.com" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , PANKAJ MISHRA , Ajeet Kumar Yadav , =?utf-8?B?7J207ZWZ67SJ?= , AMIT SAHRAWAT , =?utf-8?B?656E66a/?= , CPGS Subject: Re: [PATCH v2] module: check if memory leak by module. Message-ID: <20170403072402.GA24661@dhcp22.suse.cz> References: <1490767322-9914-1-git-send-email-maninder1.s@samsung.com> <20170329074522.GB27994@dhcp22.suse.cz> <20170329092332epcms5p10ae8263c6e3ef14eac40e08a09eff9e6@epcms5p1> <20170329104355.GG27994@dhcp22.suse.cz> <20170331080046.GI27098@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2897 Lines: 63 On Fri 31-03-17 10:05:29, Joel Fernandes wrote: > On Fri, Mar 31, 2017 at 1:00 AM, Michal Hocko wrote: > > On Thu 30-03-17 23:49:52, Joel Fernandes wrote: > >> Hi Michal, > >> > >> On Wed, Mar 29, 2017 at 3:43 AM, Michal Hocko wrote: > >> > On Wed 29-03-17 09:23:32, Vaneet Narang wrote: > >> >> Hi, > >> >> > >> >> >> Hmm, how can you track _all_ vmalloc allocations done on behalf of the > >> >> >> module? It is quite some time since I've checked kernel/module.c but > >> >> >> from my vague understading your check is basically only about statically > >> >> >> vmalloced areas by module loader. Is that correct? If yes then is this > >> >> >> actually useful? Were there any bugs in the loader code recently? What > >> >> >> led you to prepare this patch? All this should be part of the changelog! > >> >> > >> >> First of all there is no issue in kernel/module.c. This patch add functionality > >> >> to detect scenario where some kernel module does some memory allocation but gets > >> >> unloaded without doing vfree. For example > >> >> static int kernel_init(void) > >> >> { > >> >> char * ptr = vmalloc(400 * 1024); > >> >> return 0; > >> >> } > >> > > >> > How can you track that allocation back to the module? Does this patch > >> > actually works at all? Also why would be vmalloc more important than > >> > kmalloc allocations? > >> > >> Doesn't the patch use caller's (in this case, the module is the > >> caller) text address for tracking this? vma->vm->caller should track > >> the caller doing the allocation? > > > > Not really. First of all it will be vmalloc() to be tracked in the above > > the example because vmalloc is not inlined. And secondly even if the > > vmalloc is not inlined, but __built_in_address(0) will return the > *return address* of vmalloc: > > >From https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Return-Address.html : > "The level argument is number of frames to scan up the call stack. A > value of 0 yields the return address of the current function" yes, sorry, I meant to say s@vmalloc is not @__vmalloc_node_flags is not@ I can see some arguments to make __vmalloc_node_flags inline to make /proc/vmallocinfo output more useful but... > > caller of the vmalloc was tracked then it would be hopelessly > > insufficient because you would get coverage of the _direct_ module usage > > of vmalloc rather than anything that the module triggered and that is > > outside of the module. Which means any library function etc... > > Yes true, but I think the check is for direct allocations, done by the > module, not indirect ones... it may not be a catch-all issues type of > deal but is still IMO a good check since we already have > va->vm->caller available. I disagree. We have a full featured kmemleak to catch all potential leaks. This code is IMHO not worth it. -- Michal Hocko SUSE Labs