]> git.proxmox.com Git - mirror_zfs.git/commit - tests/zfs-tests/tests/Makefile.am
linux/copy_file_range: properly request a fallback copy on Linux <5.3
authorRob N <rob.norris@klarasystems.com>
Tue, 1 Aug 2023 18:31:11 +0000 (04:31 +1000)
committerGitHub <noreply@github.com>
Tue, 1 Aug 2023 18:31:11 +0000 (11:31 -0700)
commitead3eea3e07cdcfa6ae02b3e565baddb6a0773db
tree63911de9536cab0f7ebd47274c32bf2b2b60863b
parentfcd61d937f217baf4ae328781bd07e8bce5a6ce8
linux/copy_file_range: properly request a fallback copy on Linux <5.3

Before Linux 5.3, the filesystem's copy_file_range handler had to signal
back to the kernel that we can't fulfill the request and it should
fallback to a content copy. This is done by returning -EOPNOTSUPP.

This commit converts the EXDEV return from zfs_clone_range to
EOPNOTSUPP, to force the kernel to fallback for all the valid reasons it
might be unable to clone. Without it the copy_file_range() syscall will
return EXDEV to userspace, breaking its semantics.

Add test for copy_file_range fallbacks.  copy_file_range should always
fallback to a content copy whenever ZFS can't service the request with
cloning.

Reviewed-by: Brian Atkinson <batkinson@lanl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Kay Pedersen <mail@mkwg.de>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes #15131
module/os/linux/zfs/zpl_file_range.c
tests/runfiles/linux.run
tests/test-runner/bin/zts-report.py.in
tests/zfs-tests/tests/Makefile.am
tests/zfs-tests/tests/functional/block_cloning/block_cloning_copyfilerange_fallback.ksh [new file with mode: 0755]