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

[Brian Foster <bfoster@redhat.com>]

On Fri, Jun 13, 2025 at 04:42:00PM -0700, Joanne Koong wrote:
> On Fri, Jun 13, 2025 at 4:41 AM Brian Foster <bfoster@redhat.com> wrote:
> >
> > On Thu, Jun 12, 2025 at 02:56:56PM -0700, Joanne Koong wrote:
> > > On Thu, Jun 12, 2025 at 4:19 AM Brian Foster <bfoster@redhat.com> wrote:
...
> 
> You didn't mess up the bisect, I was able to verify that it is that
> commit that causes the issue. I misunderstood the error message and
> thought it was complaining about alignment in a struct being broken
> somewhere.
> 
> This fixes the commit:
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -1147,7 +1147,7 @@ static ssize_t fuse_send_write_pages(struct
> fuse_io_args *ia,
>  static ssize_t fuse_fill_write_pages(struct fuse_io_args *ia,
>                                      struct address_space *mapping,
>                                      struct iov_iter *ii, loff_t pos,
> -                                    unsigned int max_pages)
> +                                    unsigned int max_folios)
>  {
>         struct fuse_args_pages *ap = &ia->ap;
>         struct fuse_conn *fc = get_fuse_conn(mapping->host);
> @@ -1157,12 +1157,11 @@ static ssize_t fuse_fill_write_pages(struct
> fuse_io_args *ia,
>         int err = 0;
> 
>         num = min(iov_iter_count(ii), fc->max_write);
> -       num = min(num, max_pages << PAGE_SHIFT);
> 
>         ap->args.in_pages = true;
>         ap->descs[0].offset = offset;
> 
> -       while (num) {
> +       while (num && ap->num_folios < max_folios) {
>                 size_t tmp;
>                 struct folio *folio;
>                 pgoff_t index = pos >> PAGE_SHIFT;
> 
> 
> The bug is that I incorrectly assumed that I could use max_pages <<
> PAGE_SHIFT as the upper limit for how many bytes to copy in, but
> there's the possibility that the copy_folio_from_iter_atomic() call
> that we do can copy over bytes from the iov_iter that are less than
> the length of the folio, so using max_pages << PAGE_SHIFT as the bound
> for max_pages is wrong.
> 
> I ran the fix locally on top of origin/master (commit 27605c8c0) as
> well and verified that it fixes the issue. I'll send this fix
> upstream.
> 

Ah, great thanks. That makes sense.. I'll give it a try.

> Sorry for the inconvenience. Hope this bug didn't waste too much of
> your time. Thanks for reporting it.
> 

No worries at all, thanks for tracking it down!

Brian

> >
> > Brian
> >
> > > >
> > > > ... 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
> > > >
> > >
> >
>