linux-kernel - Re: [GIT PULL] more s390 updates for 6.18 merge window

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-=wiB4OTWTDf0oEkWtWEms8KY0KNrwMj5x+NhhTbAUGy-DA@mail.gmail.com>
Date: Thu, 9 Oct 2025 11:08:54 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alexander Gordeev <agordeev@...ux.ibm.com>
Cc: Vasily Gorbik <gor@...ux.ibm.com>, Heiko Carstens <hca@...ux.ibm.com>, linux-s390@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] more s390 updates for 6.18 merge window

On Thu, 9 Oct 2025 at 06:12, Alexander Gordeev <agordeev@...ux.ibm.com> wrote:
>
> - Remove superfluous newlines from inline assemblies to improve
>   compiler inlining decisions

I've pulled this all, and this commit probably makes the generated asm
look better to humans too, but I thought I'd just mention that quite
often the solution for "compiler does it wrong" is to just use "asm
_nline" to tell the compiler to just not count lines of asm at all
(horrible "count instructions" heuristic)

Because often the asm may be multiple lines due to things like section
directives or out-of-line things like exception table entries etc.

In the kernel, we almost never have truly *big* inline asms where not
inlining things would make any sense at all.

In fact, it might make sense to just make "asm inline" be the default
"asm", and do something like

   #define asm asm_inline

and if somebody *really* wants the compiler size heuristics for some
case, they might want to use an explicit __asm__ for that.

But from a quick look, we really have very few larger "true asm"
statements. I found some disgusting "write the whole function as an
asm" cases for alpha, where for some reason it wasn't made into a
separate '*.S' file, but that was a top-level asm, not even inlined.

Sparc has a few cases of "33 mulscc instructions in a row" due to
horrendous instruction set, and I found a couple of bigger "copypage"
implementations, but none of those actually struck me as "the compiler
shouldn't inline this".

Everything else I saw was in the "handful of instructions" range,
possibly with extra noise due to section tables etc.

All of which makes me go "we shouldn't have to even think about the
compiler not inlining these things".

             Linus