[PATCH] Linux: Fix tst-copy_file_range-large test on recent kernels [BZ #33498]

Collin Funk collin.funk1@gmail.com
Sun Oct 26 23:21:02 GMT 2025


"H.J. Lu" <hjl.tools@gmail.com> writes:

> It failed now with 32-bit build under 6.17.4 kernel:
>
> FAIL: misc/tst-copy_file_range-large
> original exit status 1
> ../sysdeps/unix/sysv/linux/tst-copy_file_range-large.c:179: numeric
> comparison failure
>    left: 2147479552 (0x7ffff000); from: copied
>   right: 4294963200 (0xfffff000); from: UINT_MAX & ~(getpagesize () - 1)

I think I see the issue. On 32-bit platforms ssize_t is a signed 32-bit
integer. Therefore I would expect it to pass with the following patch:

    $ git diff master
    diff --git a/sysdeps/unix/sysv/linux/tst-copy_file_range-large.c b/sysdeps/unix/sysv/linux/tst-copy_file_range-large.c
    index 9eafb8c425..184877b91c 100644
    --- a/sysdeps/unix/sysv/linux/tst-copy_file_range-large.c
    +++ b/sysdeps/unix/sysv/linux/tst-copy_file_range-large.c
    @@ -176,7 +176,7 @@ test_size (struct support_fuse *f, off64_t size)
          <https://github.com/torvalds/linux/commit/1e08938c3694f707bb165535df352ac97a8c75c9>.
       */
       if (copied != size)
    -    TEST_COMPARE (copied, UINT_MAX & ~(getpagesize () - 1));
    +    TEST_COMPARE (copied, (SSIZE_MAX & ~(getpagesize () - 1)));
     
       xclose (dest_fd);
       xclose (source_fd);

But that return value seems incorrect, since (UINT_MAX & PAGE_MASK)
bytes should be copied, per the fix [1]. I would have to set up a 32-bit
VM to double check. But I have a feeling we will need another Linux bug
report.

Collin

[1] https://github.com/torvalds/linux/commit/1e08938c3694f707bb165535df352ac97a8c75c9


More information about the Libc-alpha mailing list