linux-kernel - Re: [PATCH -tip] x86/locking/atomic: Use asm

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-=wgBMG7CcwvW15ULJOsVEq5QRSj+ccgaUJU+XGxJKeXEVw@mail.gmail.com>
Date: Wed, 5 Mar 2025 07:04:08 -1000
From: Linus Torvalds <torvalds@...uxfoundation.org>
To: Uros Bizjak <ubizjak@...il.com>
Cc: Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...el.com>, x86@...nel.org, 
	linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH -tip] x86/locking/atomic: Use asm_inline for atomic
 locking insns

On Tue, 4 Mar 2025 at 22:54, Uros Bizjak <ubizjak@...il.com> wrote:
>
> Even to my surprise, the patch has some noticeable effects on the
> performance, please see the attachment in [1] for LMBench data or [2]
> for some excerpts from the data. So, I think the patch has potential
> to improve the performance.

I suspect some of the performance difference - which looks
unexpectedly large - is due to having run them on a CPU with the
horrendous indirect return costs, and then inlining can make a huge
difference.
kvm
Regardless, I absolutely think that using asm_inline here is the right
thing for the locked instructions.

That said, I do want to bring up another issue: maybe it's time to
just retire the LOCK_PREFIX thing entirely?

It harkens back to Ye Olde Days when UP was the norm, and we didn't
want to pay the cost of lock prefixes when the kernel was built for
SMP but was run on an UP machine.

And honestly, none of that makes sense any more. You can't buy a UP
machine any more, and the only UP case would be some silly minimal
virtual environment, and if people really care about that minimal
case, they should just compile the kernel without SMP support.
Becxause UP has gone from being the default to being irrelevant. At
least for x86-64.

So I think we should just get rid of LOCK_PREFIX_HERE and the
smp_locks section entirely.

Which would probably obviate the need for your patch, since then the
compiler wouldn't see it as some big instruction. But your patch isn't
wrong, so this is absolutely not a NAK, more of a "we should go
further".

Hmm?

                  Linus