Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758470Ab3ENUfr (ORCPT ); Tue, 14 May 2013 16:35:47 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:60305 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758419Ab3ENUfq (ORCPT ); Tue, 14 May 2013 16:35:46 -0400 Date: Tue, 14 May 2013 21:30:28 +0100 From: Catalin Marinas To: Steven Rostedt Cc: Larry Finger , "zhangwei(Jovi)" , Steven Rostedt , Masami Hiramatsu , LKML Subject: Re: V3.10-rc1 memory leak Message-ID: <20130514203028.GA2997@MacBook-Pro.local> References: <51912567.6090507@lwfinger.net> <1368558586.6828.53.camel@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1368558586.6828.53.camel@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1904 Lines: 51 Hi Steve, On Tue, May 14, 2013 at 08:09:46PM +0100, Steven Rostedt wrote: > # find /debug/tracing/events/ -name format |xargs grep ffff8800769f7438 > /debug/tracing/events/drm/drm_vblank_event_delivered/format: field:pid_t pid; offset:8; size:4; signed:1;ffff8800769f7438 > > Thus, what it is complaining about being leaked, is currently being > used. > > I guess it's because the fields are stored on the "event class" > structure of the module. That is, the struct ftrace_event_class, which > is part of the module data section: > > struct ftrace_event_class { > char *system; > void *probe; > #ifdef CONFIG_PERF_EVENTS > void *perf_probe; > #endif > int (*reg)(struct ftrace_event_call *event, > enum trace_reg type, void *data); > int (*define_fields)(struct ftrace_event_call *); > struct list_head *(*get_fields)(struct ftrace_event_call *); > struct list_head fields; > int (*raw_init)(struct ftrace_event_call *); > }; > > > The list_head fields holds the fields and these are used to print out > the formats. For some reason, kmemleak is missing that the fields are > being assigned to this list on module load. > > Catalin, have any idea why kmemleak is not detecting that the field is > being referenced? I just got a patch today: https://lkml.org/lkml/2013/5/10/607 which could be related. If Rusty doesn't push it I'll do. But please let me know if it does not solve the problem. Thanks. -- 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/