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

Borislav Petkov <[email protected]> Wed, 1 Jul 2026 19:53:42 -0700
Newsgroups org.kernel.vger.linux-toolchains,dev.linux.lists.llvm,org.kernel.vger.linux-kernel
Message-ID <20260702025342.GJakXStrsCmIRnEwFD@fat_crate.local>
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?

If that were the case, we have a bunch more of those bugs around the tree.

Anyway, + linux-toolchains.

> 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 <[email protected]>
> ---
>  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
  
-- 
Regards/Gruss,
    Boris.

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