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@xxxxxxxxxx> 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@xxxxxxxxxx> 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
> > > >
> > >
> >
>
