Date:	Mon, 6 Jun 2016 20:06:15 +0900
From:	Taeung Song <treeze.taeung@...il.com>
To:	Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc:	linux-kernel@...r.kernel.org, Jiri Olsa <jolsa@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH v4 1/6] perf config: Use new perf_config_set__init() to
 initialize config set

Hi, Arnaldo :)
Did you have a nice weekend?

I sent this mail for nothing else but to tell the reason of v6 to you.

On 06/01/2016 01:52 AM, Taeung Song wrote:
>
>
> On 05/31/2016 10:43 PM, Arnaldo Carvalho de Melo wrote:
>> Em Tue, May 31, 2016 at 10:13:43AM +0900, Taeung Song escreveu:
>>> Instead of perf_config(), This function initialize config set
>>> collecting all configs from config files (i.e. user config
>>> ~/.perfconfig and system config $(sysconfdir)/perfconfig).
>>>
>>> If there are the same config variable both user and system
>>> config file, user config has higher priority than system config.
>>>
>>> Cc: Namhyung Kim <namhyung@...nel.org>
>>> Cc: Jiri Olsa <jolsa@...hat.com>
>>> Cc: Masami Hiramatsu <mhiramat@...nel.org>
>>> Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
>>> Signed-off-by: Taeung Song <treeze.taeung@...il.com>
>>> ---
>>>   tools/perf/util/config.c | 50
>>> +++++++++++++++++++++++++++++++++++++++++++++++-
>>>   1 file changed, 49 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
>>> index dad7d82..5d01899 100644
>>> --- a/tools/perf/util/config.c
>>> +++ b/tools/perf/util/config.c
>>> @@ -645,13 +645,61 @@ out_free:
>>>       return -1;
>>>   }
>>>
>>> +static int perf_config_set__init(struct perf_config_set *set)
>>> +{
>>> +    int ret = 0, found = 0;
>>> +    const char *home = NULL;
>>> +
>>> +    /* Setting $PERF_CONFIG makes perf read _only_ the given config
>>> file. */
>>> +    if (config_exclusive_filename)
>>> +        return perf_config_from_file(collect_config,
>>> config_exclusive_filename, set);
>>> +    if (perf_config_system() && !access(perf_etc_perfconfig(), R_OK)) {
>>> +        ret += perf_config_from_file(collect_config,
>>> perf_etc_perfconfig(), set);
>>> +        found += 1;
>>> +    }
>>> +
>>> +    home = getenv("HOME");
>>> +    if (perf_config_global() && home) {
>>> +        char *user_config = strdup(mkpath("%s/.perfconfig", home));
>>> +        struct stat st;
>>> +
>>> +        if (user_config == NULL) {
>>> +            warning("Not enough memory to process %s/.perfconfig, "
>>> +                "ignoring it.", home);
>>> +            goto out;
>>> +        }
>>> +
>>> +        if (stat(user_config, &st) < 0)
>>> +            goto out_free;
>>> +
>>> +        if (st.st_uid && (st.st_uid != geteuid())) {
>>> +            warning("File %s not owned by current user or root, "
>>> +                "ignoring it.", user_config);
>>> +            goto out_free;
>>> +        }
>>> +
>>> +        if (!st.st_size)
>>> +            goto out_free;
>>> +
>>> +        ret += perf_config_from_file(collect_config, user_config, set);
>>> +        found += 1;
>>> +out_free:
>>> +        free(user_config);
>>> +    }
>>> +out:
>>> +    if (found == 0)
>>> +        return -1;
>>> +    return ret;
>>> +}
>>> +
>>>   struct perf_config_set *perf_config_set__new(void)
>>>   {
>>>       struct perf_config_set *set = zalloc(sizeof(*set));
>>>
>>>       if (set) {
>>>           INIT_LIST_HEAD(&set->sections);
>>> -        perf_config(collect_config, set);
>>> +        if (perf_config_set__init(set) < 0)
>>> +            return NULL;
>>
>> So, the usual pattern is: alloc, init, fail? free, return NULL.
>>
>> I thought you could've been deviating from that pattern and went to look
>> at perf_config_set__init() to see if that was doing the freeing in case
>> of failure, which it shouldn't, it isn't, so I guess this is a leak on
>> failure, no?

I can modify the problem of the leak you said by simple handling
a case of failure at perf_config_set__init().
But I found preexisting small problems so I sent v6 with the three 
[BUGFIX] patches !!

If you can't agree this way to solve the leak,
I'd find other way. :)


Thanks,
Taeung


>
> You are right. And I found additional problems.
>
> First of all, as you said, if it is failed in perf_config_set__init(),
> the config set wouldn't be freed so this is a leak on failure.
>
> Secondly, if it is failed in perf_parse_file(),
> perf_parse_file() cannot return because of die()
> so perf_config_from_file() and perf_config()
> don't also return. I guess this is abnormal termination
> without the freeing.
> (The important point of this problem is die() at perf_parse_file())
>
> Thirdly, there are problems that are related to collect_config().
> If perf_config_from_file(collect_config,..) is failed
> the config set will be freed at collect_config() like below.
>
> static int collect_config(const char *var, const char *value,
>                void *perf_config_set)
> {
>
> ...
>
> out_free:
>      free(key);
>      perf_config_set__delete(set);
>      return -1;
> }
>
> And then if calling perf_config_from_file(collect_config,..)
> at perf_config_set__init() again,
> an error will happen because the config set is NULL at collect_config().
> (the error mean NULL pointer exception.)
>
>
> To conclude,
> First of all, I'll send preparatory PATCH set for this patch
> to solve the problems i.e.
>
>      1) A problem that perf_config() can't return
>         becuase of die() at perf_parse_file()
>
>      2) A problem about the freeing config set at collect_config()
>
>      3) NULL pointer exception at collect_config()
>
> And then I will send changed this patch following above patchset.
> (to solve a leak when perf_config_set__init() failed)
>
>
> Thanks,
> Taeung
>

Powered by blists - more mailing lists