From: Luis Henriques <luis@igalia.com>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: Brian Foster <bfoster@redhat.com>,
linux-fsdevel@vger.kernel.org,
Miklos Szeredi <mszeredi@redhat.com>
Subject: Re: [BUG] fuse/virtiofs: kernel module build fail
Date: Fri, 13 Jun 2025 15:06:49 +0100 [thread overview]
Message-ID: <871prn20sm.fsf@igalia.com> (raw)
In-Reply-To: <CAJnrk1aD_N6zX_htAgto_Bzo+1S-dmvgGRHaT_icbnwpVoDGsg@mail.gmail.com> (Joanne Koong's message of "Thu, 12 Jun 2025 14:56:56 -0700")
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'.
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
>>
>
next prev parent reply other threads:[~2025-06-13 14:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 11:22 [BUG] fuse/virtiofs: kernel module build fail Brian Foster
2025-06-12 21:56 ` Joanne Koong
2025-06-13 11:44 ` Brian Foster
2025-06-13 23:42 ` Joanne Koong
2025-06-14 10:55 ` Brian Foster
2025-06-13 14:06 ` Luis Henriques [this message]
2025-06-13 22:20 ` Joanne Koong
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=871prn20sm.fsf@igalia.com \
--to=luis@igalia.com \
--cc=bfoster@redhat.com \
--cc=joannelkoong@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mszeredi@redhat.com \
/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.