Re: copy_file_range evolution

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

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

I think the only exception may be system calls which add a flag
argument, where 0 means exactly the same thing as the previous system
call.

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

The code is just the same as (1), but new binaries would continue to get
ENOSYS if we switch to (3) later.

If we do (1) only and kernel updates aren't considered an escape hatch,
we could end up in a situation where we could not make either old nor
new binaries happy.

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

The kernel implementation keeps evolving, so the kernel behavior is
already a complex topic.  But taking glibc out of the equation
simplifies things.

Especially if you think about the case where glibc was compiled with
too-old kernel headers and always performs emulation, no matter what the
kernel supports.

Thanks,
Florian