[PATCH] Linux: Add test case for bug 33245

[Yury Khrustalev]

Hi Florian,

On Sat, Aug 02, 2025 at 01:42:18PM +0200, Florian Weimer wrote:
> The copy_file_range system call seems the only one that can return
> an off64_t value.  Use FUSE to exercise this, without actually
> creating such large files or copying any data.  Due to FUSE protocol
> limitations, only sizes up to UINT_MAX can be tested, but this is
> sufficient to check for the presence of bug 33245.
>
> ...
>
> +static void
> +test_size (struct support_fuse *f, off64_t size)
> +{
> +
> ...
> +  ssize_t copied = copy_file_range (source_fd, NULL, dest_fd, NULL, size, 0);
> +  /* Avoid FAIL_UNSUPPORTED if it is likely bogus due to previous
> +     copy_file_range successes.  */
> +  if (copied == -1 && errno == ENOSYS)
> +    {
> +      /* Unmounting avoids a test hang on exit.  */
> +      xclose (dest_fd);
> +      xclose (source_fd);
> +      support_fuse_unmount (f);
> +      FAIL_UNSUPPORTED ("copy_file_range not supported");
> +    }
> +
> +  TEST_COMPARE (copied, size);

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

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?

Thanks,
Yury