1
0
mirror of https://github.com/golang/go synced 2024-11-15 01:00:29 -07:00

[release-branch.go1.15] internal/poll: treat copy_file_range EPERM as not-handled

Updates #40893.
Fixes #40900.

Change-Id: I938ea4796c1e1d1e136117fe78b06ad6da8e40de
Reviewed-on: https://go-review.googlesource.com/c/go/+/249257
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Antonio Troina <thoeni@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit b0cc02e8c2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/249897
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
This commit is contained in:
Tobias Klauser 2020-08-19 16:54:36 +02:00 committed by Dmitri Shuralyov
parent f454f70344
commit 8bf83b323c

View File

@ -41,7 +41,7 @@ func CopyFileRange(dst, src *FD, remain int64) (written int64, handled bool, err
// use copy_file_range(2) again.
atomic.StoreInt32(&copyFileRangeSupported, 0)
return 0, false, nil
case syscall.EXDEV, syscall.EINVAL, syscall.EOPNOTSUPP:
case syscall.EXDEV, syscall.EINVAL, 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
@ -55,6 +55,11 @@ func CopyFileRange(dst, src *FD, remain int64) (written int64, handled bool, err
//
// If the file is on NFS, we can see EOPNOTSUPP.
// See issue #40731.
//
// If the process is running inside a Docker container,
// we might see EPERM instead of ENOSYS. See issue
// #40893. Since EPERM might also be a legitimate error,
// don't mark copy_file_range(2) as unsupported.
return 0, false, nil
case nil:
if n == 0 {