linux-kernel - Re: [RFC 00/13] perf_env/CPU socket reorg/fixes

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]

Message-ID: <20150911133606.GM23511@kernel.org>
Date:	Fri, 11 Sep 2015 10:36:06 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	"Wangnan (F)" <wangnan0@...wei.com>
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

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

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