mirror of
https://github.com/golang/go
synced 2024-11-25 19:37:58 -07:00
beaf7f3282
There are several issues with pidfd handling today: * The zero value of a Process makes the handle field appear valid, so methods attempt to use it as a pidfd rather than falling back to the PID as they should (#67634). * If a process doesn't exist, FindProcess returns a Process with Pid == -2, which is not a compatible change (#67640). * pidfd close is racy as-is. A Release call or successful Wait will clear the handle field and close the pidfd. However, a concurrent call may have already loaded the handle field and could then proceed to use the closed FD (which could have been reopened as a different pidfd, targeting a different process) (#67641). This CL performs multiple structural changes to the internals of Process. First and foremost, each method is refactored to clearly select either pidfd or raw pid mode. Previously, raw pid mode was structured as a fallback when pidfd mode is unavailable. This works fine, but it does not make it clear that a given Process object either always uses pidfd or always uses raw pid. Since each mode needs to handle different race conditions, it helps to make it clear that we can't switch between modes within a single Process object. Second, pidfd close safety is handled by reference counting uses of the FD. The last user of the FD will close the FD. For example, this means that with concurrent Release and Signal, the Signal call may be the one to close the FD. This is the bulk of this CL, though I find the end result makes the overall implementation easier to reason about. Third, the PID path handles a similar race condtion between Wait and Kill: Wait frees the PID value in the kernel, which could be reallocated causing Kill to target the wrong process. This is handled with a done flag and a mutex. The done flag now shares the same state field used for the handle. Similarly, the Windows implementation reuses all of the handle reference counting that Linux uses. This means the implementations more consistent, and make Windows safe against the same handle reuse problems. (Though I am unsure if Windows ever reuses handles). Wait has a slight behavior change on Windows: previously Wait after Release or an earlier Wait would hang indefinitely (WaitForSingleObject on syscall.InvalidHandle waits indefinitely). Now it returns the same errors as Linux (EINVAL and ErrProcessDone, respectively). Similarly, Release on Windows no longer returns close errors, as it may not actually be the place where the close occurs. Fixes #67634. Fixes #67640. Fixes #67641. Updates #67642. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest Change-Id: I2ad998f7b67d32031e6f870e8533dbd55d3c3d10 Reviewed-on: https://go-review.googlesource.com/c/go/+/588675 Reviewed-by: Austin Clements <austin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> |
||
|---|---|---|
| .. | ||
| archive | ||
| arena | ||
| bufio | ||
| builtin | ||
| bytes | ||
| cmd | ||
| cmp | ||
| compress | ||
| container | ||
| context | ||
| crypto | ||
| database/sql | ||
| debug | ||
| embed | ||
| encoding | ||
| errors | ||
| expvar | ||
| flag | ||
| fmt | ||
| go | ||
| hash | ||
| html | ||
| image | ||
| index/suffixarray | ||
| internal | ||
| io | ||
| iter | ||
| log | ||
| maps | ||
| math | ||
| mime | ||
| net | ||
| os | ||
| path | ||
| plugin | ||
| reflect | ||
| regexp | ||
| runtime | ||
| slices | ||
| sort | ||
| strconv | ||
| strings | ||
| structs | ||
| sync | ||
| syscall | ||
| testdata | ||
| testing | ||
| text | ||
| time | ||
| unicode | ||
| unique | ||
| unsafe | ||
| vendor | ||
| all.bash | ||
| all.bat | ||
| all.rc | ||
| bootstrap.bash | ||
| buildall.bash | ||
| clean.bash | ||
| clean.bat | ||
| clean.rc | ||
| cmp.bash | ||
| go.mod | ||
| go.sum | ||
| make.bash | ||
| make.bat | ||
| Make.dist | ||
| make.rc | ||
| race.bash | ||
| race.bat | ||
| README.vendor | ||
| run.bash | ||
| run.bat | ||
| run.rc | ||
Vendoring in std and cmd
========================
The Go command maintains copies of external packages needed by the
standard library in the src/vendor and src/cmd/vendor directories.
There are two modules, std and cmd, defined in src/go.mod and
src/cmd/go.mod. When a package outside std or cmd is imported
by a package inside std or cmd, the import path is interpreted
as if it had a "vendor/" prefix. For example, within "crypto/tls",
an import of "golang.org/x/crypto/cryptobyte" resolves to
"vendor/golang.org/x/crypto/cryptobyte". When a package with the
same path is imported from a package outside std or cmd, it will
be resolved normally. Consequently, a binary may be built with two
copies of a package at different versions if the package is
imported normally and vendored by the standard library.
Vendored packages are internally renamed with a "vendor/" prefix
to preserve the invariant that all packages have distinct paths.
This is necessary to avoid compiler and linker conflicts. Adding
a "vendor/" prefix also maintains the invariant that standard
library packages begin with a dotless path element.
The module requirements of std and cmd do not influence version
selection in other modules. They are only considered when running
module commands like 'go get' and 'go mod vendor' from a directory
in GOROOT/src.
Maintaining vendor directories
==============================
Before updating vendor directories, ensure that module mode is enabled.
Make sure that GO111MODULE is not set in the environment, or that it is
set to 'on' or 'auto', and if you use a go.work file, set GOWORK=off.
Requirements may be added, updated, and removed with 'go get'.
The vendor directory may be updated with 'go mod vendor'.
A typical sequence might be:
cd src # or src/cmd
go get golang.org/x/net@master
go mod tidy
go mod vendor
Use caution when passing '-u' to 'go get'. The '-u' flag updates
modules providing all transitively imported packages, not only
the module providing the target package.
Note that 'go mod vendor' only copies packages that are transitively
imported by packages in the current module. If a new package is needed,
it should be imported before running 'go mod vendor'.