Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759866AbZJPOMf (ORCPT ); Fri, 16 Oct 2009 10:12:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759144AbZJPOMe (ORCPT ); Fri, 16 Oct 2009 10:12:34 -0400 Received: from cam-admin0.cambridge.arm.com ([193.131.176.58]:38515 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758982AbZJPOMe (ORCPT ); Fri, 16 Oct 2009 10:12:34 -0400 To: Zdenek Kabelac Cc: Li Zefan , Linux Kernel Mailing List , Steven Rostedt , Frederic Weisbecker , Ingo Molnar Subject: Re: Leaks in trace reported by kmemleak References: <4AD6EF65.6080602@cn.fujitsu.com> <1255605778.10164.49.camel@pc1117.cambridge.arm.com> <1255690674.3008.24.camel@pc1117.cambridge.arm.com> From: Catalin Marinas Date: Fri, 16 Oct 2009 15:11:23 +0100 In-Reply-To: (Zdenek Kabelac's message of "Fri\, 16 Oct 2009 15\:32\:59 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 16 Oct 2009 14:11:24.0915 (UTC) FILETIME=[8B9AAC30:01CA4E6A] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1827 Lines: 47 Zdenek Kabelac wrote: > Yes -same - though I forget to mention that log contained these two > extra messages: > (got lost in other debug stuff :( )... > > So it could be the parameters in your first patch were not correct ? > > [drm] Initialized drm 1.1.0 20060810 > kmemleak: Scan area larger than object 0xffffffffa033b000 Ah, I forgot that kmemleak_scan_area takes an offset inside an object rather than an absolute address. Something like below (I should actually change this prototype of this function, it doesn't need to be so complex): diff --git a/kernel/module.c b/kernel/module.c index 8b7d880..8cc4406 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2383,6 +2383,10 @@ static noinline struct module *load_module(void __user *umod, "_ftrace_events", sizeof(*mod->trace_events), &mod->num_trace_events); + kmemleak_scan_area(mod->module_core, (unsigned long)mod->trace_events - + (unsigned long)mod->module_core, + sizeof(*mod->trace_events) * mod->num_trace_events, + GFP_KERNEL); #endif #ifdef CONFIG_FTRACE_MCOUNT_RECORD /* sechdrs[0].sh_size is always zero */ > BTW - it's kind of ugly - that module removal destroys stack trace - > it would be nice to see some hook for module unload - to eventually > create a permanent stack trace for this occasion?? Kmemleak only uses whatever stacktrace mechanism is available in the kernel. Resolving the symbol names when objects are allocated would slow it down and it takes up more space in the traces. I don't have a proper solution. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/