linux-kernel - Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck

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: <CAHk-=wgxD6DPv1H_uZX4MVB5GvFyGduzMFu2qAeb5dBrE=nHog@mail.gmail.com>
Date: Sun, 27 Apr 2025 09:39:55 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oliver Sang <oliver.sang@...el.com>
Cc: Arnd Bergmann <arnd@...db.de>, oe-lkp@...ts.linux.dev, 
	kernel test robot <lkp@...el.com>, linux-kernel@...r.kernel.org, 
	Ingo Molnar <mingo@...nel.org>, John Stultz <jstultz@...gle.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Stephen Boyd <sboyd@...nel.org>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [linus:master] [x86/cpu] f388f60ca9: BUG:soft_lockup-CPU##stuck_for#s![swapper:#]

On Sat, 26 Apr 2025 at 22:49, Oliver Sang <oliver.sang@...el.com> wrote:
>
> We reran the tests. if only enable X86_TSC, the various issues still
> exists. if only enable X86_CMPXCHG64, various issues gone.

Well, that's unexpected. I really didn't expect X86_CMPXCHG64 to make
any difference, since we should still use the cmpxchg64 instruction,
just with the alternative re-writing instead of directly.

Thanks for re-running the tests.

All the non-cmpxchg64 code sequences get replaced by the cmpxchg64
ones dynamically, so it all shouldn't matter one whit.

Except for during early boot. Because we do default to the old i386
sequences all the way *until* we do the alternatives replacement with
the good cmpxchg64 ones.

It does change code generation, in that we have to have that
alternative which now can be a call, so it's not a complete no-op, but
I'm still surprised.

And except for not using CMPXCHG_LOCKREF at all, but that should be
just a performance thing, and not noticeable during boot.

Hmm...

I'd love to understand why X86_CMPXCHG64 apparently matters, but I
can't convince myself that it's worth really pursuing.

            Linus