From: Yunfeng Ye <yeyunfeng@huawei.com>
To: John Garry <john.garry@huawei.com>, <peterz@infradead.org>,
<mingo@redhat.com>, <acme@kernel.org>, <mark.rutland@arm.com>,
<alexander.shishkin@linux.intel.com>, <jolsa@redhat.com>,
<namhyung@kernel.org>, <ak@linux.intel.com>,
<lukemujica@google.com>, <kan.liang@linux.intel.com>,
<yuzenghui@huawei.com>
Cc: <linux-kernel@vger.kernel.org>, <hushiyuan@huawei.com>,
<linfeilong@huawei.com>
Subject: Re: [PATCH] perf jevents: Fix resource leak in process_mapfile()
Date: Wed, 16 Oct 2019 18:58:36 +0800 [thread overview]
Message-ID: <0cd0d259-e806-effd-5e44-fccd13842697@huawei.com> (raw)
In-Reply-To: <87e66585-1564-3523-59f6-cab15b7e1717@huawei.com>
On 2019/10/16 18:40, John Garry wrote:
> On 16/10/2019 08:47, Yunfeng Ye wrote:
>> There are memory leaks and file descriptor resource leaks in
>> process_mapfile().
>>
>> Fix this by adding free() and fclose() on the error paths.
>>
>> Fixes: 80eeb67fe577 ("perf jevents: Program to convert JSON file")
>> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
>> ---
>> tools/perf/pmu-events/jevents.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
>> index e2837260ca4d..6e60d4cff592 100644
>> --- a/tools/perf/pmu-events/jevents.c
>> +++ b/tools/perf/pmu-events/jevents.c
>> @@ -758,6 +758,7 @@ static int process_mapfile(FILE *outfp, char *fpath)
>> char *line, *p;
>> int line_num;
>> char *tblname;
>> + int ret = 0;
>>
>> pr_info("%s: Processing mapfile %s\n", prog, fpath);
>>
>> @@ -769,6 +770,7 @@ static int process_mapfile(FILE *outfp, char *fpath)
>> if (!mapfp) {
>> pr_info("%s: Error %s opening %s\n", prog, strerror(errno),
>> fpath);
>> + free(line);
>> return -1;
>> }
>>
>> @@ -795,7 +797,8 @@ static int process_mapfile(FILE *outfp, char *fpath)
>> /* TODO Deal with lines longer than 16K */
>> pr_info("%s: Mapfile %s: line %d too long, aborting\n",
>> prog, fpath, line_num);
>> - return -1;
>> + ret = -1;
>> + goto out;
>
> There's a subtle change of behaviour here, i.e. now calling print_mapping_table_suffix(), but I don't think that it makes any difference.
>
yes, I know that "goto out" will run print_mapping_table_suffix(outfp), because the error path before is done like this.
so I think it should be use "goto out" to run run print_mapping_table_suffix(outfp).
> However, does outfp remain open also in this case:
>
Because it has a comment that "Make build fail", so I am not handle the outfp, only modify the process_mapfile() function.
> main(int argc, char *argv[])
> {
> ...
>
> if (process_mapfile(eventsfp, mapfile)) {
> pr_info("%s: Error processing mapfile %s\n", prog, mapfile);
> /* Make build fail */
> return 1;
> }
>
> return 0;
>
> empty_map:
> fclose(eventsfp);
> ...
> }
>
> I think that this code works on the basis that the program exits on any sort of error and releases resources automatically. Having said that, it is a good practice to tidy up.
>
I agree with you, when program exits, it will releases resources automatically. It's just to make the program clearer and more correct.
> John
>
>> }
>> line[strlen(line)-1] = '\0';
>>
>> @@ -825,7 +828,9 @@ static int process_mapfile(FILE *outfp, char *fpath)
>>
>> out:
>> print_mapping_table_suffix(outfp);
>> - return 0;
>> + fclose(mapfp);
>> + free(line);
>> + return ret;
>> }
>>
>> /*
>>
>
>
>
> .
>
next prev parent reply other threads:[~2019-10-16 10:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 7:47 [PATCH] perf jevents: Fix resource leak in process_mapfile() Yunfeng Ye
2019-10-16 10:11 ` Jiri Olsa
2019-10-16 10:40 ` John Garry
2019-10-16 10:58 ` Yunfeng Ye [this message]
2019-10-16 12:08 ` John Garry
2019-10-16 12:49 ` Yunfeng Ye
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0cd0d259-e806-effd-5e44-fccd13842697@huawei.com \
--to=yeyunfeng@huawei.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=hushiyuan@huawei.com \
--cc=john.garry@huawei.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=linfeilong@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukemujica@google.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox