All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Voytik <voytikd@gmail.com>
To: Alexander Potapenko <glider@google.com>,
	Borislav Petkov <bp@alien8.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ankur Arora <ankur.a.arora@oracle.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	Marco Elver <elver@google.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	kasan-dev@googlegroups.com, linux-mm@kvack.org,
	llvm@lists.linux.dev, Dmitry Voytik <voytikd@gmail.com>
Subject: [PATCH] x86/mm: fix objtool failure with KMSAN enabled
Date: Wed,  1 Jul 2026 14:51:51 +0200	[thread overview]
Message-ID: <20260701125151.352632-1-voytikd@gmail.com> (raw)

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


             reply	other threads:[~2026-07-01 12:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 12:51 Dmitry Voytik [this message]
2026-07-01 13:18 ` [PATCH] x86/mm: fix objtool failure with KMSAN enabled Alexander Potapenko
2026-07-01 14:45   ` Dmitry Voytik
2026-07-01 15:15     ` Alexander Potapenko
2026-07-01 22:47       ` Dmitry Voytik
2026-07-02  2:53 ` Borislav Petkov
2026-07-02 10:41   ` Dmitry Voytik
2026-07-02 11:15     ` Peter Zijlstra
2026-07-02 19:46       ` Thomas Gleixner
2026-07-02 20:05         ` Thomas Gleixner
2026-07-03 10:34           ` Dmitry Voytik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260701125151.352632-1-voytikd@gmail.com \
    --to=voytikd@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=justinstitt@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=llvm@lists.linux.dev \
    --cc=mingo@redhat.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=peterz@infradead.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.