Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932716AbdCaIAy (ORCPT ); Fri, 31 Mar 2017 04:00:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:37206 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754001AbdCaIAx (ORCPT ); Fri, 31 Mar 2017 04:00:53 -0400 Date: Fri, 31 Mar 2017 10:00:46 +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: <20170331080046.GI27098@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> 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: 1810 Lines: 40 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 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... -- Michal Hocko SUSE Labs