Re: objtool: undefined stack state in folio_zero_user()

[Alexander Potapenko]

On Wed, Jul 1, 2026 at 5:18 PM Alexander Potapenko <glider@xxxxxxxxxx> wrote:
>
> On Tue, Jun 30, 2026 at 8:36 PM Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
> >
> > On Tue, Jun 30 2026 at 15:54, Peter Zijlstra wrote:
> >
> > > + KMSAN / clang folks
> > >
> > > On Tue, Jun 30, 2026 at 12:44:35PM +0200, Peter Zijlstra wrote:
> > >> On Mon, Jun 22, 2026 at 04:23:46PM +0300, Dmitry Antipov wrote:
> > >> > As of ef0c9f75a195 ("lib: Add stale 'raid6' directory to .gitignore file")
> > >> > with clang 22.1.8 and KMSAN enabled, objtool stucks in folio_zero_user():
> > >> >
> > >> > $ ./tools/objtool/objtool --hacks=jump_label --hacks=noinstr \
> > >> >   --hacks=skylake --ibt --prefix=16 --orc --retpoline --rethunk \
> > >> >   --static-call --uaccess --no-unreachable --noinstr  --unret --link \
> > >> >   vmlinux.o
> > >> > vmlinux.o: warning: objtool: folio_zero_user+0x947: undefined stack state
> > >> > vmlinux.o: error: objtool: folio_zero_user+0x947: unknown CFA base reg -1
> > >> >
> > >> > Dmitry
> > >>
> > >> > 0000000001533940 <folio_zero_user>:
> > >>
> > >> >  1534272:  48 89 e1                mov    %rsp,%rcx
> > >> >  1534275:  48 85 ed                test   %rbp,%rbp
> > >> >  1534278:  8b 54 24 1c             mov    0x1c(%rsp),%edx
> > >> >  153427c:  0f 85 c2 00 00 00       jne    1534344 <folio_zero_user+0xa04>
> > >> >  1534282:  31 c0                   xor    %eax,%eax
> > >> >  1534284:  48 89 cc                mov    %rcx,%rsp
> > >> >  1534287:  4c 89 f7                mov    %r14,%rdi                        ;; HERE
> > >>
> > >> ...
> > >> >  1534327:  48 89 64 24 78          mov    %rsp,0x78(%rsp)
> > >> ...
> > >> >  153433a:  48 8b 4c 24 78          mov    0x78(%rsp),%rcx
> > >> >  153433f:  e9 31 ff ff ff          jmp    1534275 <folio_zero_user+0x935>
> > >>
> > >>
> > >> This is well insane codegen, and I cannot blame objtool for hating on it
> > >> -- in fact, I hate on it too.
> > >>
> > >> Let me try and figure out how best to fix this insane compiler output.
> > >
> > >
> > > This seems to 'work', but it is somewhat yuck.
> >
> > It makes the build fail go away, but the resulting kernel compiled with
> > clang22 refuses to boot. It stops here:
> >
> > [    0.283753] mem auto-init: stack:off, heap alloc:off, heap free:off
> > [    0.433144] stackdepot: allocating hash table via alloc_large_system_hash
> > [    0.433656] stackdepot hash table entries: 524288 (order: 11, 8388608 bytes, linear)
> > [    0.435775] stackdepot: allocating space for 8192 stack pools via memblock
> > [    0.462747] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> > [    0.463268] Starting KernelMemorySanitizer
> > [    0.463527] ATTENTION: KMSAN is a debugging tool! Do not use it on production machines!
> >
> > When I attach gdb to the VM then it sits in the ASM entry code of the
> > page fault handler, but the stack looks damaged and it seems to loop
> > somewhere around there forever. Haven't had time to dig into it further.
> >
> > .config is here: https://tglx.de/~tglx/config.fail
>
> If I switch to the frame pointer unwinder the kernel actually boots.
> Could ORC also need some massaging for this fix to work?

Something along the lines of:

--- a/tools/objtool/arch/x86/orc.c
+++ b/tools/objtool/arch/x86/orc.c
@@ -22,6 +22,11 @@ int init_orc_entry(struct orc_entry *orc, struct
cfi_state *cfi, struct instruct
                return 0;
        }

+       if (cfi->cfa.base == CFI_UNDEFINED) {
+               orc->type = ORC_TYPE_UNDEFINED;
+               return 0;
+       }
+
        switch (cfi->type) {
        case UNWIND_HINT_TYPE_UNDEFINED:
                orc->type = ORC_TYPE_UNDEFINED;
@@ -70,9 +75,10 @@ int init_orc_entry(struct orc_entry *orc, struct
cfi_state *cfi, struct instruct
        case CFI_DX:
                orc->sp_reg = ORC_REG_DX;
                break;
+       case CFI_UNDEFINED:
        default:
-               ERROR_INSN(insn, "unknown CFA base reg %d", cfi->cfa.base);
-               return -1;
+               orc->type = ORC_TYPE_UNDEFINED;
+               return 0;
        }