internal/poll: treat copy_file_range EPERM as not-handled

Fixes #40893

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>
diff --git a/src/internal/poll/copy_file_range_linux.go b/src/internal/poll/copy_file_range_linux.go
index 7e67125..09de299 100644
--- a/src/internal/poll/copy_file_range_linux.go
+++ b/src/internal/poll/copy_file_range_linux.go
@@ -41,7 +41,7 @@
 			// 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 @@
 			//
 			// 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 {