[PATCH] Linux: Add test case for bug 33245

H.J. Lu hjl.tools@gmail.com
Sat Sep 27 22:53:19 GMT 2025


On Thu, Sep 25, 2025 at 7:31 PM Yury Khrustalev <yury.khrustalev@arm.com> wrote:
>
> On Thu, Sep 25, 2025 at 01:08:11PM +0200, Florian Weimer wrote:
> > * Yury Khrustalev:
> >
> > > This comparison fails on Debian 13 with recent kernel 6.12.48+deb13-arm64
> > > (it works fine on 6.12.43+deb13-arm64) for copy sizes like 0xfffff001,
> > > for example:
> > >
> > > ../sysdeps/unix/sysv/linux/tst-copy_file_range-large.c:173: numeric comparison failure
> > >    left: 4294963200 (0xfffff000); from: copied
> > >   right: 4294963201 (0xfffff001); from: size
> >
> > Is this a 64-bit build?
>
> Yes, this is a 64-bit build. This happens when I build natively for
> aarch64 or cross-build for this target.
>
> > > I can't find changelog for 6.12.48+deb13 right now, but reading man page
> > > for copy_file_range() I can see that it can copy less number of files than
> > > requested and it should not be an error. Is there anything in this test
> > > that should force copy_file_range() to always copy as many bytes as
> > > requested?
> >
> > Yes, the FUSE layer (or the VFS?) was changed after I reported this to
> > the FUSE maintainers.  Previously the code path to the FUSE callback was
> > completely clean and no such shortening could happen.
>
> I see. I suppose test can be fixed to account for this?
>
> Thanks,
> Yury
>

I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=33498

-- 
H.J.


More information about the Libc-alpha mailing list