Re: ERROR: modpost: "kmsan_handle_dma" [drivers/virtio/virtio_ring.ko] undefined!

[Josh Poimboeuf]

On Tue, Feb 18, 2025 at 02:28:55PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 18, 2025 at 12:48:57PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2025-02-15 06:42:36 [+0800], kernel test robot wrote:
> > > >> arch/x86/kvm/cpuid.o: warning: objtool: do_cpuid_func+0x2428: undefined stack state
> > 
> 
> > From the assembly it seems to make sense:
> > |   110ae:       49 89 e0                mov    %rsp,%r8
> > stash for later
> > |   110b1:       48 85 db                test   %rbx,%rbx
> > |   110b4:       c7 00 00 00 00 00       movl   $0x0,(%rax)
> > |   110ba:       45 89 7e 14             mov    %r15d,0x14(%r14)
> > |   110be:       0f 85 40 01 00 00       jne    11204 <do_cpuid_func+0x22f4>
> > …
> > |   11204:       44 8b 74 24 38          mov    0x38(%rsp),%r14d
> > |   11209:       44 89 f7                mov    %r14d,%edi
> > |   1120c:       4d 89 c7                mov    %r8,%r15
> > 
> > mov rsp to r15
> 
> This, objtool doesn't track this one. It only does:
> 
>  mov %rsp, reg
> 
>  mov reg, %rsp
> 
> I'm not entirely sure how painful it would be to teach objtool about
> this case. Horrible code it is :/
> 
> > restore rsp. I just don't see how rsp is destroyed but this could be
> > related to paravirt's xxl clobbing in__cpuid().
> > 
> > I miss 1120c in my output. I don't understand how it jumps from 110ae to
> > 1124b. It misses the assignments in between but this might not be goal
> > here…

FYI, you can add OBJTOOL_ARGS="--backtrace" or OBJTOOL_VERBOSE=1 to the
cmdline to see how objtool got there.  On my build there were some
ALTERNATIVE()s involved which makes it trickier to follow.

There's definitely some weirdness going on, I'm also seeing the .s not
match the .o.  Maybe it's the __msan_*() stuff.  Still looking...

-- 
Josh