Re: objtool: undefined stack state in folio_zero_user()

[Thomas Gleixner <tglx@kernel.org>]

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

Thanks,

        tglx