[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170823104155.27f7c6f6@gandalf.local.home>
Date: Wed, 23 Aug 2017 10:41:55 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Chunyu Hu <chuhu@...hat.com>
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] tracing: Fix kmemleak in set_trigger_filter
On Wed, 23 Aug 2017 10:38:36 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> > +++ b/kernel/trace/trace_events_trigger.c
> > @@ -739,7 +739,7 @@ int set_trigger_filter(char *filter_str,
> > /* The filter is for the 'trigger' event, not the triggered event */
> > ret = create_event_filter(file->event_call, filter_str, false, &filter);
>
> The filter is allocated by create_event_filter. If that returns a
> failure, then that should be the one to free it. It is bad taste to
> require the calling function to require it.
I take that back. I just read the comment above create_event_filter():
* On success, returns 0 and *@...terp points to the new filter. On
* failure, returns -errno and *@...terp may point to %NULL or to a new
* filter. In the latter case, the returned filter contains error
* information if @set_str is %true and the caller is responsible for
* freeing it.
So filter contains an error string when it fails. It seems that we
should somehow propagate that up the chain to display. I'll look more
into this.
-- Steve
Powered by blists - more mailing lists