Re: [PATCH] x86/csum: Relax the len and proto constraints in 32-bit csum_ipv6_magic()

[Borislav Petkov]

On Mon, Oct 19, 2026 at 05:56:44PM -0700, Rosen Penev wrote:
> On Mon, Oct 19, 2026 at 5:32 PM Sasha Levin <sashal@xxxxxxxxxx> wrote:
> >
> > Building an i386 allmodconfig kernel with clang fails since allmodconfig
> > started building netfilter with GCOV profiling:
> >
> >   In file included from net/netfilter/nf_synproxy_core.c:7:
> >   In file included from ./include/linux/skbuff.h:26:
> >   In file included from ./include/net/checksum.h:21:
> >   In file included from ./arch/x86/include/asm/checksum.h:9:
> >   ./arch/x86/include/asm/checksum_32.h:149:6: error: inline assembly requires more registers than available
> >
> > The csum_ipv6_magic() asm needs five registers at once: the early-clobber
> > sum plus register-only inputs for saddr, daddr, htonl(len) and
> > htonl(proto). With frame pointers enabled, six general purpose registers
> > are left to choose from.
> >
> > In synproxy_send_tcp_ipv6(), the GCOV instrumentation lets clang's
> > machine scheduler move the copies of two incoming register arguments,
> > EDX and ECX, below the asm. Both registers then stay live across the
> > asm, which leaves four registers for its five operands. This is LLVM
> > issue #206307. The error goes away without either GCOV or frame
> > pointers, and it reproduces with clang 19, 21 and 22.
> >
> > Neither len nor proto has to be in a register: adcl also takes a 32-bit
> > memory or immediate source operand. Use "g" for both, so the asm needs
> > at most three registers whatever the caller looks like.
> >
> > ASM_INPUT_G, which normally replaces "g" to avoid clang's poor handling
> > of it, is not enough here. It expands to "ir" for clang, so callers that
> > pass a variable protocol, like nf_ip6_checksum(), would still need five
> > registers. With "g", clang passes a non-constant len or proto through
> > the stack and still turns constants into immediates.
> >
> > Fixes: 403cec8ab6d0 ("netfilter: add option for GCOV profiling")
> > Reported-by: kernelci.org bot <bot@xxxxxxxxxxxx>
> > Closes: https://dashboard.kernelci.org/build/maestro:6ad55fe255fda507603d2651
> > Reported-by: Jeff Johnson <jeff.johnson@xxxxxxxxxxxxxxxx>
> > Closes: https://lore.kernel.org/a28df759-d0e9-41c0-97c7-5f89a18d54e2@xxxxxxxxxxxxxxxx
> > Assisted-by: LLM
> > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx
> > Link: https://github.com/llvm/llvm-project/issues/206307
> > ---
> > KernelCI's kbuild-clang-21-i386-allmodconfig job has failed on mainline
> > with this error since the 7.2 merge window, v7.3 included.

This'll tell you how much people including us care about 32-bit...

> > Tested on i386 with KernelCI's allmodconfig-based .config: with clang
> > 19.1.7, 21.1.8 and 22.1.8, nf_synproxy_core.o fails before this change
> > and builds after it, and net/{netfilter,ipv4,ipv6,bridge}/ and
> > arch/x86/lib/ build without errors or warnings. The same directories
> > also build cleanly with GCC 16.2 (i386 allmodconfig). A 32-bit userspace
> > harness comparing the asm against a C reference over 2M random and
> > carry-edge inputs shows no mismatches with either compiler. No full
> > allmodconfig build or boot test.
> >
> >  arch/x86/include/asm/checksum_32.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/checksum_32.h b/arch/x86/include/asm/checksum_32.h
> > index 17da953879976..f74873a5e3510 100644
> > --- a/arch/x86/include/asm/checksum_32.h
> > +++ b/arch/x86/include/asm/checksum_32.h
> > @@ -159,7 +159,7 @@ static inline __sum16 csum_ipv6_magic(const struct in6_addr *saddr,
> >             "adcl $0, %0        ;\n"
> >             : "=&r" (sum)
> >             : "r" (saddr), "r" (daddr),
> > -             "r" (htonl(len)), "r" (htonl(proto)), "0" (sum)
> > +             "g" (htonl(len)), "g" (htonl(proto)), "0" (sum)
> >             : "memory");
> Same as https://lore.kernel.org/all/20260904000833.2058186-1-rosenp@xxxxxxxxx/

Except that Sasha's commit message explains it perfectly clear how this
happens while for yours I would've asked how you're reproducing this.

OTOH, I'm not sure I care about Sasha's AI's blurb about what params should've
been in what registers and so on... :)

If only you guys would agree on how to merge the two, assign authorship and
drop the unnecessary blurb...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette