Re: [BUG] fuse/virtiofs: kernel module build fail

[Joanne Koong <joannelkoong@gmail.com>]

On Fri, Jun 13, 2025 at 7:06 AM Luis Henriques <luis@igalia.com> wrote:
>
> On Thu, Jun 12 2025, Joanne Koong wrote:
>
> > On Thu, Jun 12, 2025 at 4:19 AM Brian Foster <bfoster@redhat.com> wrote:
> >>
> >> Hi folks,
> >>
> >> I run kernel compiles quite a bit over virtiofs in some of my local test
> >> setups and recently ran into an issue building xfs.ko once I had a
> >> v6.16-rc kernel installed in my guest. The test case is a simple:
> >>
> >>   make -j N M=fs/xfs clean; make -j N M=fs/xfs
> >
> > Hi Brian,
> >
> > If I'm understanding your setup correctly, basically you have the
> > v6.16-rc kernel running on a VM, on that VM you mounted a virtiofs
> > directory that references a linux repo that's on your host OS, and
> > then from your VM you are compiling the fs/xfs module in that shared
> > linux repo?
> >
> > I tried this on my local setup but I'm seeing some other issues:
> >
> > make[1]: Entering directory '/home/vmuser/linux/linux/fs/xfs'
> >   LD [M]  xfs.o
> > xfs.o: warning: objtool: __traceiter_xfs_attr_list_sf+0x23:
> > unannotated intra-function call
> > make[3]: *** [/home/vmuser/linux/linux/scripts/Makefile.build:501:
> > xfs.o] Error 255
> > make[3]: *** Deleting file 'xfs.o'
> > make[2]: *** [/home/vmuser/linux/linux/Makefile:2006: .] Error 2
> > make[1]: *** [/home/vmuser/linux/linux/Makefile:248: __sub-make] Error 2
> > make[1]: Leaving directory '/home/vmuser/linux/linux/fs/xfs'
> > make: *** [Makefile:248: __sub-make] Error 2
> >
> > Did you also run into these issues when you were compiling?
>
> This is probably just a shot in the dark, but I remember seeing similar
> build failures long time ago due to virtiofs caching.  I don't remember
> the details, but maybe it's worth checking that.  I *think* that what
> fixed it for me was to use '--cache auto'.

Thanks for the tip. I just tried it again with --cache=auto but I'm
still seeing the same issue.

>
> Cheers,
> --
> Luís
>
>
> > Taking a look at what 63c69ad3d18a ("fuse: refactor
> > fuse_fill_write_pages()") does, it seems odd to me that the changes in
> > that commit would lead to the issues you're seeing - that commit
> > doesn't alter structs or memory layouts in any way. I'll keep trying
> > to repro the issue you're seeing.
> >
> >>
> >> ... and ends up spitting out link time errors like this as of commit
> >> 63c69ad3d18a ("fuse: refactor fuse_fill_write_pages()"):
> >>
> >> ...
> >>   CC [M]  xfs.mod.o
> >>   CC [M]  .module-common.o
> >>   LD [M]  xfs.ko
> >>   BTF [M] xfs.ko
> >> die__process: DW_TAG_compile_unit, DW_TAG_type_unit, DW_TAG_partial_unit or DW_TAG_skeleton_unit expected got subprogram (0x2e) @ ed957!
> >> error decoding cu i_mmap_rwsem
> >> error decoding cu
> >> ...
> >> error decoding cu
> >> pahole: xfs.ko: Invalid argument
> >> make[3]: *** [/root/repos/linux/scripts/Makefile.modfinal:57: xfs.ko] Error 1
> >> make[3]: *** Deleting file 'xfs.ko'
> >> make[2]: *** [/root/repos/linux/Makefile:1937: modules] Error 2
> >> make[1]: *** [/root/repos/linux/Makefile:248: __sub-make] Error 2
> >> make[1]: Leaving directory '/root/repos/linux/fs/xfs'
> >> make: *** [Makefile:248: __sub-make] Error 2
> >>
> >> ... or this on latest master:
> >>
> >> ...
> >>   LD [M]  fs/xfs/xfs.o
> >> fs/xfs/xfs.o: error: objtool: can't find reloc entry symbol 2145964924 for .rela.text
> >> make[4]: *** [scripts/Makefile.build:501: fs/xfs/xfs.o] Error 1
> >> make[4]: *** Deleting file 'fs/xfs/xfs.o'
> >> make[3]: *** [scripts/Makefile.build:554: fs/xfs] Error 2
> >> make[2]: *** [scripts/Makefile.build:554: fs] Error 2
> >> make[1]: *** [/root/repos/linux/Makefile:2006: .] Error 2
> >> make: *** [Makefile:248: __sub-make] Error 2
> >>
> >> The latter failure is what I saw through most of a bisect so I suspect
> >> one of the related followon commits alters the failure characteristic
> >> from the former, but I've not confirmed that. Also note out of
> >> convenience my test was to just recompile xfs.ko out of the same tree I
> >> was bisecting from because the failures were consistent and seemed to be
> >> a runtime kernel issue and not a source tree issue.
> >>
> >> I haven't had a chance to dig any further than this (and JFYI I'm
> >> probably not going to be responsive through the rest of today). I just
> >> completed the bisect and wanted to get it on list sooner rather than
> >> later..
> >>
> >> Brian
> >>
> >
>