lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 14 Sep 2015 09:37:16 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	Kan Liang <kan.liang@...el.com>, Ingo Molnar <mingo@...nel.org>,
	<linux-kernel@...r.kernel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Borislav Petkov <bp@...e.de>, David Ahern <dsahern@...il.com>,
	"Frederic Weisbecker" <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [RFC 00/13] perf_env/CPU socket reorg/fixes



On 2015/9/11 21:36, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 11, 2015 at 10:30:52AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Sep 11, 2015 at 10:29:37AM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Fri, Sep 11, 2015 at 10:03:39AM -0300, Arnaldo Carvalho de Melo escreveu:
>>>> Em Fri, Sep 11, 2015 at 08:20:54PM +0800, Wangnan (F) escreveu:
>>>>> I have tested patch 1 to 10. They looks good to me except patch 4/13. Please
>>>> Ok, I'll take that as a Tested-by: you for 1-10 with 4/13 having the
>>>> checks added, ok?
>>>   
>>>>> see my email in that thread.
>>>   
>>>> I add those checks.
>>> Ok, below is the diff for adding the checks. The get_{core,socket}_id
>>> functions should be moved to tools/lib/api/cpu.[ch], using the same
>>> interface as cpu__get_max_freq(&value), using the int return value to
>>> propagate the precise error, etc. Will do it in a follow up patch.
>> Humm, but then, what happens if a CPU is offline? I'm checking it now...
>    # cat /sys/devices/system/cpu/cpu3/topology/core_id
>    3
>    # cat
>    /sys/devices/system/cpu/cpu3/topology/physical_package_id
>    0
>    # echo 0 > /sys/devices/system/cpu/cpu3/online
>    # cat
>    /sys/devices/system/cpu/cpu3/topology/physical_package_id
>    cat: /sys/devices/system/cpu/cpu3/topology/physical_package_id: No such file or directory
>    # cat /sys/devices/system/cpu/cpu3/topology/core_id
>    cat: /sys/devices/system/cpu/cpu3/topology/core_id: No such file or directory
>    #
>
> So we shouldn't check the result, right? We could further validate it by
> checking:
>
>    # cat /sys/devices/system/cpu/cpu3/online
>    0
>    #
>
> But assuming that not being able to access it means it is offline looks
> almost reasonable, if not strictly correct, so I'm removing the tests
> and will revisit this when I move those functions to
> tools/lib/api/cpu.[ch].

I highly suspect that setting 'online' to 0 is not the only reason of
the removal of topology directory. Testing the existance of the two
files should be better.

Thank you.

> - Arnaldo
>
>>> diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
>>> index 6af4f7c36820..2e4cad84197b 100644
>>> --- a/tools/perf/util/env.c
>>> +++ b/tools/perf/util/env.c
>>> @@ -60,7 +60,7 @@ out_enomem:
>>>   
>>>   int perf_env__read_cpu_topology_map(struct perf_env *env)
>>>   {
>>> -	int cpu, nr_cpus;
>>> +	int cpu, nr_cpus, err;
>>>   
>>>   	if (env->cpu != NULL)
>>>   		return 0;
>>> @@ -77,10 +77,17 @@ int perf_env__read_cpu_topology_map(struct perf_env *env)
>>>   		return -ENOMEM;
>>>   
>>>   	for (cpu = 0; cpu < nr_cpus; ++cpu) {
>>> -		env->cpu[cpu].core_id	= cpu_map__get_core_id(cpu);
>>> -		env->cpu[cpu].socket_id	= cpu_map__get_socket_id(cpu);
>>> +		err = env->cpu[cpu].core_id = cpu_map__get_core_id(cpu);
>>> +		if (err < 0)
>>> +			goto out_free;
>>> +		err = env->cpu[cpu].socket_id = cpu_map__get_socket_id(cpu);
>>> +		if (err < 0)
>>> +			goto out_free;
>>>   	}
>>>   
>>> -	env->nr_cpus_avail = nr_cpus;
>>>   	return 0;
>>> +
>>> +out_free:
>>> +	zfree(&env->cpu);
>>> +	return err;
>>>   }


--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ