Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

internal/poll: CopyFileRange returns EPERM on CircleCI Docker Host running 4.10.0-40-generic [1.15 backport] #40900

Closed
gopherbot opened this issue Aug 19, 2020 · 3 comments
Closed

internal/poll: CopyFileRange returns EPERM on CircleCI Docker Host running 4.10.0-40-generic [1.15 backport] #40900

gopherbot opened this issue Aug 19, 2020 · 3 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone
Go1.15.2

Comments

@gopherbot
Copy link
Contributor

@tklauser requested issue #40893 to be considered for backport to the next 1.15 minor release.

@gopherbot please consider backporting this to 1.15.

The use of copy_file_range is new in 1.15 and this causes failures doing file system operations in containers running on older kernels which do not provide the copy_file_range syscall.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Aug 19, 2020
@gopherbot gopherbot mentioned this issue Aug 19, 2020
Closed
@gopherbot gopherbot added this to the Go1.15.1 milestone Aug 19, 2020
@problame problame mentioned this issue Aug 21, 2020
Closed
@dmitshur
Copy link
Contributor

Approved per discussion in a release meeting. Only 1.15 needs this backport.

@dmitshur dmitshur added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Aug 21, 2020
@gopherbot
Copy link
Contributor Author

Change https://golang.org/cl/249897 mentions this issue: [release-branch.go1.15] internal/poll: treat copy_file_range EPERM as not-handled

@gopherbot
Copy link
Contributor Author

Closed by merging 8bf83b3 to release-branch.go1.15.

gopherbot pushed a commit that referenced this issue Aug 22, 2020
@tklauser @dmitshur
[release-branch.go1.15] internal/poll: treat copy_file_range EPERM as…
8bf83b3 
… 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 b0cc02e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/249897
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
@dmitshur dmitshur modified the milestones: Go1.15.1, Go1.15.2 Sep 1, 2020
rurban pushed a commit to rurban/coreutils that referenced this issue May 15, 2021
@pixelb
copy: handle system security config issues with copy_file_range()
2e66e17 
* src/copy.c (sparse_copy): Upon EPERM from copy_file_range(),
fall back to a standard copy, which will give a more accurate
error as to whether the issue is with the source or destination.
Also this will avoid the issue where seccomp or apparmor are
not configured to handle copy_file_range(), in which case
the fall back standard copy would succeed without issue.
This specific issue with seccomp was noticed for example in:
golang/go#40900
@golang golang locked and limited conversation to collaborators Sep 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Projects
None yet
Milestone
Go1.15.2
Development

No branches or pull requests
2 participants
@dmitshur @gopherbot