[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53B639DE.8030102@hitachi.com>
Date: Fri, 04 Jul 2014 14:21:34 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Namhyung Kim <namhyung@...il.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
Tom Zanussi <tom.zanussi@...ux.intel.com>,
"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
linux-kernel@...r.kernel.org,
"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: __trace_remove_event_dirs() leaks file->filter ? (Was: probe_event_disable()->synchronize_sched())
(2014/07/04 2:01), Oleg Nesterov wrote:
> On 07/03, Oleg Nesterov wrote:
>>
>> Hmm. Off-topic, but it seems that instance_rmdir() leaks the memory? Say,
>> file->filter?
>
> Perhaps I am totally confused, but don't we need something like the patch
> below? I'll try to recheck later...
>
> Better yet, we can probably move destroy_preds() from event_remove() to
> remove_event_file_dir()... not sure, need to recheck.
Ah, yes, it seems event_remove releases preds, and remove_event_file_dir()
called from event_trace_del_tracer() doesn't release it.
BTW, with following patch, we'd better remove destroy_preds() from
event_remove() and add destroy_call_preds() at the very last of the
function.
Thank you,
>
> Oleg.
>
> --- x/kernel/trace/trace_events.c
> +++ x/kernel/trace/trace_events.c
> @@ -470,6 +470,7 @@ static void remove_event_file_dir(struct ftrace_event_file *file)
>
> list_del(&file->list);
> remove_subsystem(file->system);
> + destroy_file_preds(file);
> kmem_cache_free(file_cachep, file);
> }
>
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists