[PATCH v2] Subject: copy_file_range.2: glibc no longer provides fallback after 2.30

[Wes Gibbs <wg21908@gmail.com>]

Update the documentation to note that glibc no longer provides a
user-space fallback for copy_file_range() when the system call is
not available, as of glibc 2.30. Applications must now handle ENOSYS
themselves.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=220489
Signed-off-by: Wes Gibbs <wg21908@gmail.com>
---
 man/man2/copy_file_range.2 | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/man/man2/copy_file_range.2 b/man/man2/copy_file_range.2
index e9e9e9945..5146c0d11 100644
--- a/man/man2/copy_file_range.2
+++ b/man/man2/copy_file_range.2
@@ -202,10 +202,16 @@ that was also backported to earlier stable kernels.
 .SH STANDARDS
 Linux, GNU.
 .SH HISTORY
-Linux 4.5,
-but glibc 2.27 provides a user-space
-emulation when it is not available.
+Linux 4.5.
+Before glibc 2.30, the glibc wrapper function provided a user-space
+fallback implementation when the kernel did not implement this
+system call. Since glibc 2.30, that fallback has been removed; the
+function now fails with ENOSYS if the kernel lacks support for
+.BR copy_file_range ().
+.\" Fallback introduced in glibc 2.27:
 .\" https://sourceware.org/git/?p=glibc.git;a=commit;f=posix/unistd.h;h=bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f
+.\" Fallback removed in glibc 2.30:
+.\" https://sourceware.org/git/?p=glibc.git;a=commit;h=50c6ee3e74e08b8205f18dfb2830e9ec1bcf2ad4
 .SH NOTES
 If
 .I fd_in
-- 
2.48.1