Re: [PATCH] copy: disallow copy_file_range() on Linux kernels before 5.3

[Kaz Kylheku (Coreutils)]

On 2021-05-12 16:09, Pádraig Brady wrote:
> copy_file_range() before Linux kernel release 5.3 had many issues,

Remark: although there is nothing wrong with the patch, and it is
necessary, this seems like an issue for the C library to handle,
as well.

- The GNU C library provides the function copy_file_range. The
  fact that this is a linux kernel feature is abstracted by the library.

- The GNU C library knows what version of the kernel it is running on,
  and provides workarounds in relation to that (or possibly refuses
  to run at all).

So, arguably, the responsibility of somehow working around this lies
with glibc; glibc is the purveyor of the API.

Unfortunately, I don't see any discussions about the issue in
libc-alpha mailing list.

The situation is not acceptable that a GNU program is working around
broken GNU library functions, with no action being taken in the
GNU library (even if that program will need to carry those workarounds
anyway).

The most recent commits which mention copy_file_range in the
commit message are:

2020-03-03 	 Florian Weimer	Linux: copy_file_range syscall number is 
always available
2019-07-08       DJ Delorie     NEWS: clarify copy_file_range
2019-06-28 	 Florian Weimer	io: Remove copy_file_range emulation [BZ 
#24744]

(I am obviously assuming that any commit related to this issue
will have "copy_file_range" in the commit message.)

The comment for that third one is interesting:

  The kernel is evolving this interface (e.g., removal of the
  restriction on cross-device copies), and keeping up with that
  is difficult.  Applications which need the function should
  run kernels which support the system call instead of relying on
  the imperfect glibc emulation.

Glibc should not be providing a function like this at all
until it stabilizes. Programs wanting to use a bleeding edge
kernel call should use a some syscall macro to generate it
themselves.

It sounds as if now that it may have stabilized, glibc should
be offering it under a different name/alias.

Programs that need a reliable copy_file_range can then just
refer to that new name which indicates reliable semantics. They
detect that name in their configure scripts, and build and
link against that name. Those programs will then refuse to
run against a glibc which doesn't export that name.
Problem solved.