linux-kernel - Re: [PATCH] compiler/gcc: Make asm() templates asm __inline_

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: <CAFULd4bxUOiPLQ9aaZFx2jsLUwEPH0h=XiCOtxYn+Z8JEAeHUw@mail.gmail.com>
Date: Thu, 20 Mar 2025 09:21:42 +0100
From: Uros Bizjak <ubizjak@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, "H. Peter Anvin" <hpa@...or.com>, 
	linux-kernel@...r.kernel.org, Juergen Gross <jgross@...e.com>, 
	Stefano Stabellini <sstabellini@...nel.org>, "Ahmed S . Darwish" <darwi@...utronix.de>, 
	Andrew Cooper <andrew.cooper3@...rix.com>, John Ogness <john.ogness@...utronix.de>, 
	Peter Zijlstra <peterz@...radead.org>, Borislav Petkov <bp@...en8.de>, 
	Thomas Gleixner <tglx@...utronix.de>, Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH] compiler/gcc: Make asm() templates asm __inline__() by default

On Wed, Mar 19, 2025 at 11:34 PM Ingo Molnar <mingo@...nel.org> wrote:
>
>
> * Uros Bizjak <ubizjak@...il.com> wrote:
>
> > On Tue, Mar 18, 2025 at 9:11 PM Ingo Molnar <mingo@...nel.org> wrote:
> >
> > >  #ifdef CONFIG_CC_HAS_ASM_INLINE
> > >  # define asm_inline __asm__ __inline
> > >  # define asm(...) asm_inline(__VA_ARGS__)
> > >  #else
> > >  # define asm_inline asm
> > >  #endif
> > >
> > > And I fixed up the places where this isn't syntactically correct:
> > >
> > >  35 files changed, 82 insertions(+), 79 deletions(-)
> > >
> > > I haven't looked at code generation much yet, but text size changes are
> > > minimal:
> > >
> > >       text         data     bss      dec            hex filename
> > >   29429076      7931870 1401196 38762142        24f769e vmlinux.before
> > >   29429631      7931870 1401200 38762701        24f78cd vmlinux.after
> > >
> > > Which is promising, assuming I haven't messed up anywhere.
> >
> > Please use bloat-o-meter, it is more precise.
>
> Here's the bloat-o-meter output between vanilla and patched vmlinux:

[...]

> A lot fewer functions are affected than I expected from such a
> large-scope change.

Interestingly, I got *many* more changes just from converting atomic
locking functions to asm_inline, as reported in [1].

[1] https://lore.kernel.org/lkml/CAFULd4YBcG45bigHBox2pu+To+Y5BzbRxG+pUr42AVOWSnfKsg@mail.gmail.com/

> > Actually, functions with the most impact (x86 locking functions and
> > __arch_hweight) were recently converted to asm_inline, so besides
> > __untagged_addr, the remaining have very little impact, if at all
> > (c.f. amd_clear_divider() ). There is also no need to convert asm()
> > without directives inside.
>
> I did the test with Linus-vanilla (81e4f8d68c66) to maximize the
> potential effect, which doesn't have those changes yet.
>
> See tip:WIP.x86/core.
>
> > My proposal would be to convert the remaining few cases (the remaining
> > asms involving ALTERNATIVE and exceptions) "by hand" to asm_inline()
> > and stick a rule in checkpatch to use asm_inline() in the code
> > involving asm(), like we have the rule with asm volatile.
> >
> > I don't think redefining an important C keyword is a good approach, it
> > obfuscates its meaning too much. And as has been shown by Ingo's
> > experiment, there is a substantial effort to fix false positives.
> > Instead of fixing these, we can trivially convert the remaining cases
> > to asm_volatile() as well, without obfuscating asm(). Checkpatch can
> > take care of future cases.
>
> This would work for me too. The cross-arch impact and churn seems
> substantial.

Perhaps we should also coordinate the effort with Josh, so we won't
step on each other's toes. From my analysis, gains from converting the
remaining asm() that involve ALTERNATIVE would be minor. It is also
questionable if asm() involving exceptions is worth converting at all,
I have to analyse them case-by-case some more during the next
development window.

Thanks,
Uros.