[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