internal/poll: drop redundant ENOSYS in CopyFileRange

Update CL 425881 and CL 428396

I browsed the source code related to copy_file_range in the kernel and found that the latest kernel may still return EXDEV errors in copy_file_range(2) due to certain cases, for details see: https://elixir.bootlin.com/linux/v5.19.7/source/fs/read_write.c#L1559, https://elixir.bootlin.com/linux/v5.19.7/source/fs/read_write.c#L1479, and
https://elixir.bootlin.com/linux/v5.19.7/source/fs/read_write.c#L1439.

Therefore, the EXDEV still needs to be kept, but the ENOSYS error can be safely removed.

Change-Id: I47026b8dd33f7ffc4de1306af6b67c7b4d2062d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/428555
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
This commit is contained in:
Andy Pan 2022-09-06 20:08:05 +08:00 committed by Gopher Robot
parent 86477e507f
commit 4f3246c6e9

View file

@ -41,22 +41,18 @@ func CopyFileRange(dst, src *FD, remain int64) (written int64, handled bool, err
}
n, err := copyFileRange(dst, src, int(max))
switch err {
case syscall.ENOSYS:
// copy_file_range(2) was introduced in Linux 4.5.
// Go supports Linux >= 2.6.33, so the system call
// may not be present.
//
// If we see ENOSYS, we have certainly not transferred
// any data, so we can tell the caller that we
// couldn't handle the transfer and let them fall
// back to more generic code.
return 0, false, nil
case syscall.EXDEV, syscall.EINVAL, syscall.EIO, syscall.EOPNOTSUPP, syscall.EPERM:
// Prior to Linux 5.3, it was not possible to
// copy_file_range across file systems. Similarly to
// the ENOSYS case above, if we see EXDEV, we have
// not transferred any data, and we can let the caller
// fall back to generic code.
// copy_file_range across file systems. An attempt
// to do this will result in a EXDEV error.
//
// Even though we have checked the kernel version and blocked
// the attempts to copy_file_range(2) when the kernel version
// is older than 5.3, but until now the latest kernel (5.19.x)
// may still return EXDEV error in certain cases.
//
// If we see EXDEV, we have not transferred any data,
// and we can let the caller fall back to generic code.
//
// As for EINVAL, that is what we see if, for example,
// dst or src refer to a pipe rather than a regular