copy_file_range evolution

[Florian Weimer <fweimer at redhat dot com>]

We currently have emulation for copy_file_range.  I thought it was
possible to implement fairly accurate userspace emulation, but I have
doubts now.  What has changed?

I did not consider the case where both descriptors refer to the same
open file description.  Source and destination offsets in
copy_file_range can either be implied or explicit.  Matching the kernel
behavior looks difficult.

The emulation does not check an overlapping range, but the kernel does
this (or will do it).  It probably produces garbage in this case.

There are further kernel changes coming, such as cross-device support.

I think we should retire the userspace emulation.  We have three options
for that:

(1) A thin system call wrapper (returning ENOSYS without kernel
support), with the existing symbol versions.

(2) The same, but with a dual symbol version including GLIBC_2.30.  This
means that we can split the implementation for old binaries and
transition to the next solution.

(3) A full compat symbol with the current implementation, plus a thin
wrapper for new binaries.

My preference is (1), with an expectation that affected binaries will be
“fixed” by running them on a kernel which actually supports the
copy_file_range system call.

Thoughts?

Thanks,
Florian