[Bug build/26338] io/tst-copy_file_range fails on RHEL 7.8 hosts

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26338

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Romain Geissler from comment #0)
> Hi,
> 
> Following an internal mail exchange with folks from Red Hat, I would like to
> notify you that right now the test io/tst-copy_file_range is failing on
> kernel 3.10.0-1127.13.1.el7.x86_64 from RHEL 7.8 (while it used to work on
> earlier RHEL 7 kernels).
> 
> It looks like on the RHEL kernel the backported syscall copy_file_range has
> had different behavior over time in the RHEL 7 kernel, and with RHEL 7.8 it
> ended up being deprecated in some use cases. See
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
> html/7.8_release_notes/deprecated_functionality and this paragraph in
> particular:
> 
> The copy_file_range() call has been disabled on local file systems and in NFS
> The copy_file_range() system call on local file systems contains multiple
> issues that are difficult to fix. To avoid file corruptions,
> copy_file_range() support on local file systems has been disabled in RHEL
> 7.8. If an application uses the call in this case, copy_file_range() now
> returns an ENOSYS error.
> 
> It happens that this description from Red Hat is not fully accurate.
> Actually, you *CAN* call copy_file_range on a RHEL 7.8 kernel and a local
> file system, it will return 0 if the size of the copy is 0 as well, and
> ENOSYS if the size of the copy is different from 0.

This behavior in misleading and it means that it might not be possible to
check if the syscall is supported without triggering side-effects, since
it seems that ENOSYS is being returned later when the syscall calls the
filesystem callbacks.

> 
> The code in io/tst-copy_file_range which flags the test as unsupported on
> the running system looks like this:
> 
>  240   infd = create_temp_file ("tst-copy_file_range-in-", &infile);
>  241   outfd = create_temp_file ("tst-copy_file_range-out-", &outfile);
>  242   {
>  243     ssize_t ret = copy_file_range (infd, NULL, outfd, NULL, 0, 0);
>  244     if (ret != 0)
>  245       {
>  246         if (errno == ENOSYS)
>  247           FAIL_UNSUPPORTED ("copy_file_range is not support on this
> system");
>  248         FAIL_EXIT1 ("copy_file_range probing call: %m");
>  249       }
>  250   }
> 
> So basically on these RHEL 7.8 kernel the first "copy_file_range" with size
> of 0 are successfull, and the test is *NOT* marked as unsupported, while
> actually it is.
> 
> May I suggest to cope with this case by ensuring we do copy more than 0
> bytes, and if we get ENOSYS flag the whole test as unsupported ?

If it is a RHEL7.8 specific issue due the non-upstream change to disable it
I think the test should keep as-is, since it does indicate non expected
failure in the syscall semantic regarding upstream behaviour.

-- 
You are receiving this mail because:
You are on the CC list for the bug.