linux-kernel - Re: Kernel 6.9 regression: X86: Bogus messages from topology detection

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: Fri, 31 May 2024 15:42:26 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Christian Heusel <christian@...sel.eu>
Cc: Peter Schneider <pschneider1968@...glemail.com>, LKML
 <linux-kernel@...r.kernel.org>, x86@...nel.org, stable@...r.kernel.org,
 regressions@...ts.linux.dev
Subject: Re: Kernel 6.9 regression: X86: Bogus messages from topology detection

On Fri, May 31 2024 at 15:08, Christian Heusel wrote:
> On 24/05/31 11:11AM, Thomas Gleixner wrote:
>> On Fri, May 31 2024 at 10:48, Thomas Gleixner wrote:
>> 
>> It seems there are two different issues here. The dmesg you provided is
>> from a i7-1255U, which is a hybrid CPU. The i7-7700k has 4 cores (8
>> threads) and there is not necessarily the same root cause.
>
> It seems like I was also below my needed caffeine levels :p The person
> reporting (in the same thread) with the i7-7700k reports the problem
> fixed[1] as well, so this is in line with Peters observerations!

Cool!

> The other person with the i7-1255U in the meantime got back to me with
> the needed outputs:
>> - output of cpuid -r

> 0x0000000b: subleafs:
>   0: EAX=0x00000001, EBX=0x00000001, ECX=0x00000100, EDX=0x00000012
>   1: EAX=0x00000006, EBX=0x0000000c, ECX=0x00000201, EDX=0x00000012

> 0x0000001f: subleafs:
>   0: EAX=0x00000001, EBX=0x00000001, ECX=0x00000100, EDX=0x00000012
>   1: EAX=0x00000007, EBX=0x0000000c, ECX=0x00000201, EDX=0x00000012

So this is inconsistent already. Both leafs should describe the same
topology. See the differing EAX values (6/7) in subleaf 1, which are
exactly the values the kernel complains about :)

But that should not be an issue because the kernel preferres 0x1f over
0xb and will never evaluate both, but this is just from one randomly
picked CPU.

I wonder which variant of the cpuid tool that is. cpuid -r gives you
usually just the plain values and collects them for all CPUs.

I really need to have the values for all CPUs to see whether there are
differences at the relevant places. The above is probably from one of
the E-Cores.

Thanks,

        tglx