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

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

[Dmitry Voytik]

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.
Additionally, reintroduce asm_inline to prevent potential compiler
rejection of inlining.

Link: https://lore.kernel.org/CAAX90H2_RPnZL_dFYN7cQF6yt-wAweKKSx2=6e2aZ0kv+Pm+NQ@mail.gmail.com
Signed-off-by: Dmitry Voytik <voytikd@gmail.com>
---
 arch/x86/include/asm/page_64.h | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h
index 1895c207f629..de8604f0a3a1 100644
--- a/arch/x86/include/asm/page_64.h
+++ b/arch/x86/include/asm/page_64.h
@@ -100,12 +100,13 @@ static inline void clear_pages(void *addr, unsigned int npages)
 	 * __clear_pages_unrolled() are part of the inline asm register
 	 * specification.
 	 */
-	asm volatile(ALTERNATIVE_2("call __clear_pages_unrolled",
-				   "shrq $3, %%rcx; rep stosq", X86_FEATURE_REP_GOOD,
-				   "rep stosb", X86_FEATURE_ERMS)
-			: "+c" (len), "+D" (addr), ASM_CALL_CONSTRAINT
-			: "a" (0)
-			: "cc", "memory");
+	asm_inline volatile(
+		ALTERNATIVE_2("call __clear_pages_unrolled",
+			      "shrq $3, %%rcx; rep stosq", X86_FEATURE_REP_GOOD,
+			      "rep stosb", X86_FEATURE_ERMS)
+		: ASM_CALL_CONSTRAINT, "+c"(len), "+D"(addr)
+		: "a"(0)
+		: "cc", "memory");
 }
 #define clear_pages clear_pages
 
-- 
2.54.0

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

[Alexander Potapenko]

On Wed, Jul 1, 2026 at 2:51 PM Dmitry Voytik <voytikd@gmail.com> 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.
> Additionally, reintroduce asm_inline to prevent potential compiler
> rejection of inlining.
>
> Link: https://lore.kernel.org/CAAX90H2_RPnZL_dFYN7cQF6yt-wAweKKSx2=6e2aZ0kv+Pm+NQ@mail.gmail.com
> Signed-off-by: Dmitry Voytik <voytikd@gmail.com>
Have you tried running KMSAN with this fix?

I tried running with the config that Thomas posted at
https://lore.kernel.org/all/87tsqjq3i3.ffs@fw13/
(https://tglx.de/~tglx/config.fail), and it still hangs for me.

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

[Dmitry Voytik]

Hi Alexander,

On Wed, Jul 1, 2026 at 3:18 PM Alexander Potapenko <glider@google.com> wrote:
>
> On Wed, Jul 1, 2026 at 2:51 PM Dmitry Voytik <voytikd@gmail.com> 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.
> > Additionally, reintroduce asm_inline to prevent potential compiler
> > rejection of inlining.
> >
> > Link: https://lore.kernel.org/CAAX90H2_RPnZL_dFYN7cQF6yt-wAweKKSx2=6e2aZ0kv+Pm+NQ@mail.gmail.com
> > Signed-off-by: Dmitry Voytik <voytikd@gmail.com>
> Have you tried running KMSAN with this fix?
>
> I tried running with the config that Thomas posted at
> https://lore.kernel.org/all/87tsqjq3i3.ffs@fw13/
> (https://tglx.de/~tglx/config.fail), and it still hangs for me.

I only tested the fix with defconfig + CONFIG_KMSAN +
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT + olddefconfig.

qemu-system-x86_64 \
    -kernel arch/x86/boot/bzImage \
    -append "console=ttyS0" \
    -nographic \
    -m 8G -smp 4 \
    -serial file:serial_output.log

Booting from ROM..
[    0.000000] Linux version 7.1.0-14280-g3dd2bc904bda
(voyt@voyt-laptop-dell) (clang version 22.1.6, LLD 22.1.6) #2 SMP
PREEMPT_DYNAMIC Wed Jul  1 16:25:28 CEST 2026
...
[    2.274314] Starting KernelMemorySanitizer
[    2.274356] ATTENTION: KMSAN is a debugging tool! Do not use it on
production machines!
[    2.357699] Dynamic Preempt: lazy
[    2.390793] rcu: Preemptible hierarchical RCU implementation.
[    2.391032] rcu:     RCU event tracing is enabled.
[    2.391256] rcu:     RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
...
[   53.009112] /dev/root: Can't open blockdev
[   53.012357] VFS: Cannot open root device "" or unknown-block(0,0): error -6
[   53.013186] Please append a correct "root=" boot option; here are
the available partitions:
...

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

[Alexander Potapenko]

On Wed, Jul 1, 2026 at 4:45 PM Dmitry Voytik <voytikd@gmail.com> wrote:
>
> Hi Alexander,
>
> On Wed, Jul 1, 2026 at 3:18 PM Alexander Potapenko <glider@google.com> wrote:
> >
> > On Wed, Jul 1, 2026 at 2:51 PM Dmitry Voytik <voytikd@gmail.com> 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.
> > > Additionally, reintroduce asm_inline to prevent potential compiler
> > > rejection of inlining.
> > >
> > > Link: https://lore.kernel.org/CAAX90H2_RPnZL_dFYN7cQF6yt-wAweKKSx2=6e2aZ0kv+Pm+NQ@mail.gmail.com
> > > Signed-off-by: Dmitry Voytik <voytikd@gmail.com>
> > Have you tried running KMSAN with this fix?
> >
> > I tried running with the config that Thomas posted at
> > https://lore.kernel.org/all/87tsqjq3i3.ffs@fw13/
> > (https://tglx.de/~tglx/config.fail), and it still hangs for me.
>
> I only tested the fix with defconfig + CONFIG_KMSAN +
> CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT + olddefconfig.
>
> qemu-system-x86_64 \
>     -kernel arch/x86/boot/bzImage \
>     -append "console=ttyS0" \
>     -nographic \
>     -m 8G -smp 4 \
>     -serial file:serial_output.log
>
> Booting from ROM..
> [    0.000000] Linux version 7.1.0-14280-g3dd2bc904bda
> (voyt@voyt-laptop-dell) (clang version 22.1.6, LLD 22.1.6) #2 SMP
> PREEMPT_DYNAMIC Wed Jul  1 16:25:28 CEST 2026
> ...

In fact I think the hangs are being caused by CONFIG_UNWINDER_ORC=y,
sorry for the noise.

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

[Thomas Gleixner]

On Thu, Jul 02 2026 at 13:15, Peter Zijlstra wrote:
> 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.

With FRAME_POINTER=y I get now with clang-22

vmlinux.o: warning: objtool: folio_zero_user+0xa7b: stack state mismatch: reg1[4]=-1+0 reg2[4]=-2-336
vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x64: relocation to !ENDBR: machine_kexec_prepare+0x8f0

That's with your objtool patch applied. When I remove that then the
folio_zero_user one goes away. The relocation to !ENDBR stays.

Oh well...

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

[Thomas Gleixner]

On Thu, Jul 02 2026 at 21:46, Thomas Gleixner wrote:
> On Thu, Jul 02 2026 at 13:15, Peter Zijlstra wrote:
>> 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.
>
> With FRAME_POINTER=y I get now with clang-22
>
> vmlinux.o: warning: objtool: folio_zero_user+0xa7b: stack state mismatch: reg1[4]=-1+0 reg2[4]=-2-336
> vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x64: relocation to !ENDBR: machine_kexec_prepare+0x8f0
>
> That's with your objtool patch applied. When I remove that then the
> folio_zero_user one goes away. The relocation to !ENDBR stays.
>
> Oh well...

And none of this boots when KMSAN=y ....

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

[Dmitry Voytik]

Hi Thomas,

On Thu, Jul 2, 2026 at 10:05 PM Thomas Gleixner <tglx@kernel.org> wrote:
>
> On Thu, Jul 02 2026 at 21:46, Thomas Gleixner wrote:
> > On Thu, Jul 02 2026 at 13:15, Peter Zijlstra wrote:
> >> 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.
> >
> > With FRAME_POINTER=y I get now with clang-22
> >
> > vmlinux.o: warning: objtool: folio_zero_user+0xa7b: stack state mismatch: reg1[4]=-1+0 reg2[4]=-2-336
> > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x64: relocation to !ENDBR: machine_kexec_prepare+0x8f0
> >
> > That's with your objtool patch applied. When I remove that then the
> > folio_zero_user one goes away. The relocation to !ENDBR stays.
> >
> > Oh well...
>
> And none of this boots when KMSAN=y ....

Thanks for checking this!
I wonder if we are debugging clang here because I just retested the patch with
CONFIG_FRAME_POINTER on the current Linus' tree and it works in my env:

clang --version
clang version 22.1.6

git pull -r
git show -s --oneline -2
21f3d2b2069e (HEAD -> master) x86/mm: fix objtool failure with KMSAN enabled
d2c9a99135da (origin/master, origin/HEAD) Merge tag 'device-id-rework'
of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux

make mrproper
make LLVM=1 defconfig
./scripts/config \
  -e CONFIG_KMSAN \
  -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT \
  -e UNWINDER_FRAME_POINTER
make LLVM=1 olddefconfig
make LLVM=1 W=ce -j(nproc) bzImage

grep -e CONFIG_KMSAN= -e CONFIG_FRAME_POINTER \
  -e CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT .config

CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
CONFIG_FRAME_POINTER=y
CONFIG_KMSAN=y

qemu-system-x86_64 \
  -kernel arch/x86/boot/bzImage \
  -accel kvm \
  -append "console=ttyS0" \
  -nographic \
  -m 8G -smp 4 \
  -serial file:serial_out.log

grep -e 'Linux version' -A1 -e KernelMemorySanitizer -e 'append a
correct' serial_out.log

[    0.000000] Linux version 7.2.0-rc1-00009-gb0b29f0286be
(voyt@voyt-laptop-dell) (clang version 22.1.6, LLD 22.1.6) #1 SMP
PREEMPT_DYNAMIC Fri Jul  3 11:55:02 CEST 2026
[    0.000000] Command line: console=ttyS0
--
[    0.218380] Starting KernelMemorySanitizer
[    0.218382] ATTENTION: KMSAN is a debugging tool! Do not use it on
production machines!
--
[    4.037384] Please append a correct "root=" boot option; here are
the available partitions:
[    4.037772] 0b00         1048575 sr0


Could another CONFIG_ be the culprit on your side? Or, has your clang
version some different (buggy?) behaviour?