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: <954c7084-3d6f-47b8-b6cc-08a912eda74c@zytor.com>
Date: Sat, 8 Mar 2025 11:08:08 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Dave Hansen <dave.hansen@...el.com>, Uros Bizjak <ubizjak@...il.com>,
        x86@...nel.org, linux-kernel@...r.kernel.org
Cc: Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH -tip] x86/locking/atomic: Use asm_inline for atomic
 locking insns

On 2/28/25 08:48, Dave Hansen wrote:
> On 2/28/25 04:35, Uros Bizjak wrote:
>> The code size of the resulting x86_64 defconfig object file increases
>> for 33.264 kbytes, representing 1.2% code size increase:
>>
>>     text    data     bss     dec     hex filename
>> 27450107        4633332  814148 32897587        1f5fa33 vmlinux-old.o
>> 27483371        4633784  814148 32931303        1f67de7 vmlinux-new.o
> 
> So, first of all, thank you for including some objective measurement of
> the impact if your patches. It's much appreciated.
> 
> But I think the patches need to come with a solid theory of why they're
> good. The minimum bar for that, I think, is *some* kind of actual
> real-world performance test. I'm not picky. Just *something* that spends
> a lot of time in the kernel and ideally where a profile points at some
> of the code you're poking here.
> 
> I'm seriously not picky: will-it-scale, lmbench, dbench, kernel
> compiles. *ANYTHING*. *ANY* hardware. Run it on your laptop.
> 
> But performance patches need to come with performance *numbers*.

Incidentally, this is exactly the reason why gcc added "asm inline" *at 
our request*. We just haven't caught up with it everywhere yet.

In fact, I would wonder if we shouldn't simply do:

#define asm __asm__ __inline__
#define asm_noinline __asm__

... in other words, to make asm inline an opt-out instead of an opt-in.
It is comparatively unusual that we do complex things in inline assembly 
that we would want gcc to treat as something that should be avoided.

	-hpa