New glibc-testfail io/tst-copy_file_range with kernel-next.

[Stefan Liebler <stli at linux dot ibm dot com>]

Hi,

as information, I had the chance to run the glibc-testsuite on a 
kernel-next from today on s390x and recognized a new failing test:
io/tst-copy_file_range

It seems as the patches from Amir Golstein are changing the behaviour of 
copy_file_range. See two of the series:
-"vfs: allow copy_file_range to copy across devices"
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5dae222a5ff0c269730393018a5539cc970a4726
-"vfs: add missing checks to copy_file_range"
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=96e6e8f4a68df2d94800311163faa67124df24e5

A quick look into the verbose output (see attached file) shows at least 
the following changes:

- writing at a position past the maximum allowed offset with "write" 
fails with EINVAL (22) whereas "copy_file_range" is now returning EFBIG 
(27). The test assumes that the same errno is set for "write" and 
"copy_file_range". (See <glibc>/io/tst-copy_file_range.c in 
delayed_write_failure_beginning() with current_size=1 or the second copy 
in delayed_write_failure_end())
According to http://man7.org/linux/man-pages/man2/copy_file_range.2.html 
and http://man7.org/linux/man-pages/man2/write.2.html EFBIG seems to be 
the correct error.
Should "write" also return EFBIG in those cases?

- For delayed_write_failure_beginning() with current_size>=2 
copy_file_range is started at a valid offset, but the length is beyond a 
valid range. copy_file_range is now copying the "valid" bytes and 
returning the number of copied bytes. The old behaviour was to return 
EINVAL without copying anything.
In find_maximum_offset() a test sets maximum_offset_hard_limit to 
true/false depending on the behaviour of "write" in such a situation
and the tests in delayed_write_failure_beginning() are assuming that 
"copy_file_range" behaves like "write".
Should "write" perform the same partial copies as "copy_file_range" or 
how to determine the setting of maximum_offset_hard_limit?

- In cross_device_failure it is assumed that copy_file_range always 
fails with EXDEV. Amirs patches are now allowing this case if possible.
How could the testcase determine if the kernel supports cross device 
copies or not?


How do we usually handle those kernel-next changes?
As soon as there is an official released kernel or before?

Bye
Stefan

Attachment: tst-copy_file_range.out.verbose
Description: Text document