On Wed, Jun 30, 2021 at 6:06 PM Luis Henriques [off-list ref] wrote:

On Wed, Jun 30, 2021 at 05:56:34PM +0300, Amir Goldstein wrote:

quoted

On Wed, Jun 30, 2021 at 4:44 PM Luis Henriques [off-list ref] wrote:

quoted

A regression has been reported by Nicolas Boichat, found while using the
copy_file_range syscall to copy a tracefs file.  Before commit
5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
kernel would return -EXDEV to userspace when trying to copy a file across
different filesystems.  After this commit, the syscall doesn't fail anymore
and instead returns zero (zero bytes copied), as this file's content is
generated on-the-fly and thus reports a size of zero.

This patch restores some cross-filesystem copy restrictions that existed
prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
devices").  Filesystems are still allowed to fall-back to the VFS
generic_copy_file_range() implementation, but that has now to be done
explicitly.

nfsd is also modified to fall-back into generic_copy_file_range() in case
vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/ (local)
Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/ (local)
Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/ (local)
Reported-by: Nicolas Boichat <redacted>
Reported-by: kernel test robot <redacted>
Signed-off-by: Luis Henriques <redacted>
---
Changes since v9
- the early return from the syscall when len is zero now checks if the
  filesystem is implemented, returning -EOPNOTSUPP if it is not and 0
  otherwise.  Issue reported by test robot.

What issue was reported?

Here's the link to my previous email:

https://lore.kernel.org/linux-fsdevel/877dk1zibo.fsf@suse.de/ (local)

Sorry, I missed it. I guess the subject was not aluring enough ;-)

So your patch does not fix the root cause.
The solution is to remove the (len == 0) short-circuit as you first suggested.

The problem is this:
A program tries to check for CFR support by calling CFR with zero length.
The XFS filesystem driver (in the test robot report) supports CFR via the
remap_file_range() method in general, but not on the particular filesystem
instance that was formatted without reflink support.
The intention of the program was to test for CFR support on the particular
filesystem instance, so the short-circuit response is wrong.

Note that vfs_clone_file_range() does NOT short circuit (len == 0).
That is (allegedly) because it needs to call into the filesystem
method to know if the filesystem instance supports clone_file_range.

The reason that your patch is wrong is because the same situation
can happen with a filesystem driver that has a copy_file_range()
method, but a particular instance does not support copy_file_range().
For example, overlayfs has an ovl_copy_file_range() method, so it would
short circuit zero CFR, but if in a particular overlayfs, the upper fs does
not support CFR, then the overlayfs instance does not support CFR either.

... which reminds me that I need to also send a patch to fix the fstest.
(Although the test as-is actually allowed to find this bug...)

Not sure why you'd want to fix the test.
The test check with a zero length file seems valid to me.

Thanks,
Amir.