Re: [PATCH] x86/mm: fix objtool failure with KMSAN enabled

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Jul 02, 2026 at 12:41:09PM +0200, Dmitry Voytik wrote:
> Hi Borislav,
> 
> On Thu, Jul 2, 2026 at 4:54 AM Borislav Petkov <bp@alien8.de> wrote:
> >
> > On Wed, Jul 01, 2026 at 02:51:51PM +0200, Dmitry Voytik wrote:
> > > This patch fixes broken builds with defconfig + CONFIG_KMSAN +
> > > CONFIG_DEBUG_INFO_*.
> > >
> > > To reproduce the issue before the fix:
> > >   make mrproper
> > >   make LLVM=1 defconfig
> > >   ./scripts/config -e CONFIG_KMSAN \
> > >     -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
> > >   make LLVM=1 olddefconfig
> > >   make LLVM=1 -j(nproc) vmlinux
> > >   ...
> > >     LD      vmlinux.o
> > >   vmlinux.o: warning: objtool: folio_zero_user+0x801: undefined stack state
> > >   vmlinux.o: error: objtool: folio_zero_user+0x801: unknown CFA base reg -1
> > >   make[2]: *** [scripts/Makefile.vmlinux_o:76: vmlinux.o] Error 255
> > >
> > > objtool in verbose mode shows how the frame pointer is omitted:
> > >   make LLVM=1 OBJTOOL_VERBOSE=1 -j(nproc) vmlinux
> > >   ...
> > >   b15a2c:  folio_zero_user+0x7fc      xor    %eax,%eax
> > >   b15a2e:  folio_zero_user+0x7fe      mov    %rcx,%rsp
> > >   b15a31:  folio_zero_user+0x801      mov    %r14,%rdi
> > >   b15a34:  folio_zero_user+0x804      mov    %rbx,%rcx
> > >   b15a37:  folio_zero_user+0x807      call   0xb15a3c <__clear_pages_unrol
> > >
> > > After the fix, the frame pointer is back:
> > >   b15a37: 31 c0                       xor    %eax,%eax
> > >   b15a39: 48 89 ec                    mov    %rbp,%rsp
> > >   b15a3c: 4c 89 f7                    mov    %r14,%rdi
> > >   b15a3f: 48 89 d9                    mov    %rbx,%rcx
> > >   b15a42: e8 00 00 00 00              call   b15a47 <folio_zero_user+0x817>
> > >
> > > It seems the issue was introduced by
> > > commit 54a6b89a3db2 ("x86/mm: simplify clear_page_*")
> > >
> > > The actual fix is to revert the change how ASM_CALL_CONSTRAINT is
> > > positioned.
> >
> > Why?
> >
> > Where does it say that the current stack ptr dependency needs to be the first
> > asm input operand?
> 
> Very good question. My uneducated guess - bugs in clang.
> Out of curiosity, I compared (see below) what clang and gcc do when
> ASM_CALL_CONSTRAINT moves around, and it indeed affects generated
> code, which is weird.
> I might just be holding it wrong, like optimization must be on, etc.
> 
> > If that were the case, we have a bunch more of those bugs around the tree.
> 
> At least, it makes objtool happy for the defconfig + KMSAN.

Yeah, for all the wrong reasons. AFAICT it is one clang bug causing
another clang bug to manifest less onerous.

This ASM_CALL_CONSTRAINT placement is, for some reason, forcing a stack
frame (which is not in fact required), but having a stack frame then
avoids the absolutely retarded:

	mov %rsp, %rcx;
1:	mov %rcx, %rsp
	...
	mov %rsp, disp(%rsp)
	call __msam_foo
	mov disp(%rsp), %rcx
	test
	je 1b

construct. Becaus having the stack frame (rbp) then makes all the rsp
juggling less of a problem.

So on the one hand the __msan 'functions' are special annotated in clang
to force re-align the stack. Then it notices the stack is already
properly aligned and the actual stack alignment code goes missing, BUT
it keeps the save/restore rsp (for raisins). It then furher compounds
the failure by spilling the RSP copy onto the stack, and voila, total
and utter insanity.

I suspect you can simply remove that magic annotate for KMSAM, kernel
stacks are always aligned, there no point, what-so-ever, to do the whole
save/align/restore thing.

There is also this thread from last year, which looks to be a
similar/same problem:

  https://lore.kernel.org/174108458405.14745.4864877018394987266.tip-bot2@tip-bot2

those patches never made it in, Josh was going to rework, but that never
quite happened either.

And I think we need to, at least temporarily, deal with this, until a
fixed clang is released and we can make KMSAN depend on that version,
but I worry about the impact of this change on !KMSAN builds.

A quick test with folio_zero_user() seems to suggest the
ASM_CALL_CONSTRAINT movement (your patch) generates the same code for
defconfg as does the unmodified code. The change from the thread linked
above (input constraint on __builtin_frame_address(0)) generates
different code.

A third option is to force FRAME_POINTER=y for KMSAN builds -- for now,
until clang is taught to be less insane.