linux-kernel - Re: RFC: /proc/cpuinfo confusion with AMD processors

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: <20140630133803.GE4766@pd.tnic>
Date:	Mon, 30 Jun 2014 15:38:03 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: RFC: /proc/cpuinfo confusion with AMD processors

On Mon, Jun 30, 2014 at 09:29:05AM -0400, Prarit Bhargava wrote:
> Yes, I get that. But this doesn't uniquely identify *which* processor
> it is.

What do you mean, which processor it is? You want to know which
processor on the motherboard, physically? When you look at the mobo and
if all is enumerated regularly and you have a, say, two socket system
with the processors above, to be able to say that processor 31 is the
16th core on the second node on the motherboard? Something like that?

> Admins load systems relative to nodes, and look at /proc/cpuinfo as a
> "known" place to get that info. At the end of the day I'd like to be
> able to human-read /proc/cpuinfo and get the correct data out of it
> without jumping through hoops

What correct data? All that's there is correct AFAICT. Give an example
of what you want to do?

> to get processor location information. I can, in theory, use the
> initial apicid and the apicid to map everything out ... but I
> shouldn't have to. /proc/cpuinfo provides an easy look up for this
> data for Intel; why not for AMD?

What does it show on Intel that's clear there and that's puzzling you on
AMD?

> Additionally the turbostat utility, for example, is broken because of
> this lack of info. It assumes that /sys/../cpu/cpuX/topology/core_id
> is *per package* when on AMD systems it is reported as per node.

The turbostat utility might need some testing and fixing on AMD. If you
can get some resources to do that I think everyone will profit from it.

> I read that exact same thing somewhere else. The argument you're
> making is that it might be broken for some other reason. It already is
> completely misleading and utterly useless in the above case. A simple
> test patch to arch/x86/kernel/cpu/proc.c shows that including the
> information above is trivial. Adding it /sys/.../cpu/cpuX/topology is
> a little bit more difficult.

And I'm still saying that that information - albeit being trivial to
add - might be lying on some system doing renumbering. So, again: what
exactly do you want to be able to figure out from /proc/cpuinfo and what
is puzzling you? Give concrete examples please...

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/