linux-kernel - RE: [Patch v11 4/5] x86/cpufeature: enable RING3MWAIT for Knights Landing

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: <alpine.DEB.2.20.1612221141450.3426@nanos>
Date:   Thu, 22 Dec 2016 12:05:49 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Andrejczuk, Grzegorz" <grzegorz.andrejczuk@...el.com>
cc:     "mingo@...hat.com" <mingo@...hat.com>,
        "hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Luc, Piotr" <Piotr.Luc@...el.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: RE: [Patch v11 4/5] x86/cpufeature: enable RING3MWAIT for Knights
 Landing

On Thu, 22 Dec 2016, Andrejczuk, Grzegorz wrote:

> > Handing a typecasted unsigned int pointer to a function which expects an
> > unsigned long pointer is just broken and a clear sign of careless
> > tinkering.
> 
> I thought this to be 32 issue because it popped up in 32 build.

It also warns on the 64bit build.

> The reason for this is probably that sizeof(int) is equal to sizeof(long)
> on x64.

Huch? sizeof(int) is equal to sizeof(long) on 32bit, but definitely not on 64 bit.

> I used the cast following set_cpu_cap define which does exactly the same
> thing with u32* type.

set_cpu_cap() operates on 'c->x86_capability', which is an array of u32 and
the bit numbers are linear. That works because x86 is little endian. It's
not pretty, but it's not a template for general abuse.

> I used set_bit because I wanted to be sure that this operation to be
> done atomically. There might be data race when multiple values of
> ELF_HWCAP2 will be set by multiple threads.

Touching ELF_HWCAP2 from anything else than the boot cpu is pointless
anyway. This should be done once.

Aside of that CPU bringup and therefor the call to init_intel() is
serialized by the cpu hotplug code and if we lift that, then ELF_HWCAP2
will be the least of our worries.

Thanks,

	tglx