On 13/12/2025 08:42, Matteo Croce wrote:
Il giorno sab 13 dic 2025 alle ore 15:42 Paul Eggert
<[email protected]> ha scritto:
On 2025-12-12 20:27, Collin Funk wrote:
A recent glibc bug made it not okay, but we check for it in Gnulib
Yes, my guess is that Matteo is dealing with an older Coreutils that
lacks Gnulib's August workaround[1] for the glibc bug. We decided to
work around the glibc bug in Gnulib rather than in cat, as we don't want
to patch every program that uses copy_file_range.
[1]:
https://cgit.git.savannah.gnu.org/cgit/gnulib.git/commit/?id=948ba80168293e3d8a905eeffb0ab61424c4c374
Interesting, which glibc has the fix? I can reproduce it on Fedora 43:
$ ldd --version
ldd (GNU libc) 2.42
$ rpm -q glibc
glibc-2.42-4.fc43.aarch64
glibc-2.42-4.fc43 has the fix going by commits mentioned in
https://sourceware.org/PR33245
(otherwise I would have backported the fix to coreutils on Fedora).
In your strace I see that the large value is passed to copy_file_range
so the limit you're hitting is not the gnulib workaround.
I also see the same limit as you with the 6.17.6 kernel on Fedora 43 on btrfs
at least.
Perhaps this is a kernel level workaround for the glibc issue,
or maybe just some other kernel limit.
cheers,
Padraig
