[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B84E173.9010608@oracle.com>
Date: Wed, 24 Feb 2010 16:21:07 +0800
From: Wenji Huang <wenji.huang@...cle.com>
To: Li Zefan <lizf@...fujitsu.com>
CC: linux-kernel@...r.kernel.org, fweisbec@...il.com,
rostedt@...dmis.org
Subject: Re: [PATCH -tip 5/5] tracing: simplify memory recycle of trace_define_field
On 02/24/2010 04:04 PM, Li Zefan wrote:
> Wenji Huang wrote:
>> Discard freeing field->type since it's not necessary and may be hazard.
>>
>
> It's redundant, but it's safe, because if we run into this failure path,
> field->type is always NULL.
There are two entries to failure path, field->name == NULL or
field->type == NULL. And allocating for field->name is before field->type.
IMHO, field->type is not fixed after initialization, it's
not safe if field->name==NULL goes to failure path.
Regards,
Wenji
>
>> Signed-off-by: Wenji Huang<wenji.huang@...cle.com>
>
> Reviewed-by: Li Zefan<lizf@...fujitsu.com>
>
>> ---
>> kernel/trace/trace_events.c | 4 +---
>> 1 files changed, 1 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
>> index c2a3077..3f972ad 100644
>> --- a/kernel/trace/trace_events.c
>> +++ b/kernel/trace/trace_events.c
>> @@ -60,10 +60,8 @@ int trace_define_field(struct ftrace_event_call *call, const char *type,
>> return 0;
>>
>> err:
>> - if (field) {
>> + if (field)
>> kfree(field->name);
>> - kfree(field->type);
>> - }
>> kfree(field);
>>
>> return -ENOMEM;
--
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