Re: copy_file_range evolution

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 04/06/2019 12:17, Florian Weimer wrote:
> 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.

I think from our previous attempts of system calls emulation (pread/pwrite,
preadv/pwritev, preadv2/pwritev2, fsaccessat, etc.) that is tricky and error
prone.  I think a better strategy for Linux specific syscalls is just either
provide the wrapper or fail with a ENOSYS.  

Even for cases where it should be safe, such as preadv2/pwritev2; I think we
should just return ENOSYS for configured build without the expected __NR (since 
for this specific usage there is actually gain in calling preadv2/pwritev2
besides the small semantic difference to pwritev2 from BZ#22753).

> 
> (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.

Not sure how would be different than a compat symbol providing the current
implementation (syscall plus fallback in case of ENOSYS), and a default
one that only issues the syscall. 

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

My main issue here is a program would potentially behave differently whether
copy_file_range would be supported by the kernel. Should we really strive
for compatibility in this cases?

> 
> 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
>