linux-kernel - Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

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:   Wed, 1 Feb 2017 22:44:21 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     "Ghannam, Yazen" <Yazen.Ghannam@....com>
Cc:     x86-ml <x86@...nel.org>, Yves Dionne <yves.dionne@...il.com>,
        Brice Goglin <Brice.Goglin@...ia.fr>,
        Peter Zijlstra <peterz@...radead.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

On Wed, Feb 01, 2017 at 09:37:02PM +0000, Ghannam, Yazen wrote:
> This hunk won't work for SMT enabled systems. It'll cause all threads under
> an LLC to be considered SMT siblings. For example, threads 0 &2 will have
> different cpu_core_id, so the first check will fail. But it'll match on the
> second check since cu_id will be initialized to 0.

Good catch.

> To get around this we can set cu_id for all TOPOEXT systems, and update
> cpu_core_id, etc. for SMT enabled systems. This way we can just change
> cpu_core_id to cu_id in match_smt().

Ok, so we want to init ->cu_id to something invalid then. -1, for
example and then do:

	if (c->cu_id != -1 && o->cu_id != -1 && (c->cu_id == o->cu_id))
		...

Alternatively, we can define an X86_FEATURE_COMPUTE_UNITS or so
synthetic bit which we can check.

One thing I don't want to do is reuse ->cu_id on systems which don't
have CUs.

> I tested this patch,  with the above changes, on a Fam17h SMT enabled
> system. I'll test with SMT disabled and also on a fully-loaded Fam15h
> system soon.

Thanks!

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.