| Age | Commit message (Collapse) | Author |
|---|
|
This error is already used in three places, so let's define it.
Change-Id: I73565d94aebcf3d5a278201d96839d82db85a2d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/702436
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
Consolidate release/deactivation into a single doRelease method.
It needs to check GOOS for backward compatibility, but it's
simpler to keep all the logic in one place.
Change-Id: I242eb084d44d2682f862a8fbf55c410fb8c53358
Reviewed-on: https://go-review.googlesource.com/c/go/+/638580
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
There is no reason to use a cleanup/finalizer for a Process that
doesn't use a handle, because Release doesn't change anything visible
about the process.
For #70907
Change-Id: I3b92809175523ceee2e07d601cc2a8e8b86321e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/638579
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
It's now redundant with checking whether the handle field is nil.
For #70907
Change-Id: I877f2a7c63d15ab5f8e3d2c9aa24776c2e3e2056
Reviewed-on: https://go-review.googlesource.com/c/go/+/638576
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
|
|
This was missed in CL 627479.
Change-Id: Ibcd511573c330bf782fe6a8a50d56bb70aedf3c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/629915
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This restores behavior that we lost in CL 588675.
Fixes #68496
Change-Id: I1740986bed647835986d54109071b7a6b37413d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/599015
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
|
|
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>
|
|
This is a continuation of CL 570036.
Amend FindProcess to use pidfdFind, and make it return a special
Process with Pid of pidDone (-2) if the process is not found.
Amend Wait and Signal to return ErrProcessDone if pid == pidDone.
The alternative to the above would be to make FindProcess return
ErrProcessDone, but this is unexpected and incompatible API change,
as discussed in #65866 and #51246.
For #62654.
Rework of CL 542699 (which got reverted in CL 566476).
Change-Id: Ifb4cd3ad1433152fd72ee685d0b85d20377f8723
Reviewed-on: https://go-review.googlesource.com/c/go/+/570681
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Use Process.handle field to store pidfd, and make use of it. Only use
pidfd functionality if all the needed syscalls are available.
1. Add/use pidfdWorks, which checks that all needed pidfd-related
functionality works.
2. os.StartProcess: obtain the pidfd from the kernel, if possible, using
the functionality added by CL 520266. Note we could not modify
syscall.StartProcess to return pidfd directly because it is a public
API and its callers do not expect it, so we have to use ensurePidfd
and getPidfd.
3. (*Process).Kill: use pidfdSendSignal, if available and the pidfd is
known. Otherwise, fall back to the old implementation.
4. (*Process).Wait: use pidfdWait, if available, otherwise fall back to
using waitid/wait4. This is more complicated than expected due to
struct siginfo_t idiosyncrasy.
NOTE pidfdSendSignal and pidfdWait are used without a race workaround
(blockUntilWaitable and sigMu, added by CL 23967) because with pidfd,
PID recycle issue doesn't exist (IOW, pidfd, unlike PID, is guaranteed
to refer to one particular process) and thus the race doesn't exist
either.
Rework of CL 528438 (reverted in CL 566477 because of #65857).
For #62654.
Updates #13987.
Change-Id: If5ef8920bd8619dc428b6282ffe4fb8c258ca224
Reviewed-on: https://go-review.googlesource.com/c/go/+/570036
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
This reverts CL 528438.
Reason for revert: Implicated in "bad FD" test failures. Full extent of
issue still unclear.
For #62654.
Fixes #65857.
Change-Id: I066e38040544c506917e90255bd0e330964a0276
Reviewed-on: https://go-review.googlesource.com/c/go/+/566477
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This reverts CL 542699.
Reason for revert: Some applications assume FindProcess does not return
errors.
For #62654.
Fixes #65866.
Change-Id: Ic185a6253c8e508b08150b618c39a9905f6cdd60
Reviewed-on: https://go-review.googlesource.com/c/go/+/566476
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
|
|
Amend FindProcess to use pidfdFind, and make it return ErrProcessDone
if pidfdFind is used and the process is not found.
Since this is a change in API, introduce GODEBUG osfinderr=0 setting
to disable the feature.
Change-Id: I724c6f622f0c99f21a70b864cf7cf2b8836869ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/542699
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Use Process.handle field to store pidfd, and make use of it. Only use
pidfd functionality if all the needed syscalls are available.
1. StartProcess: obtain the pidfd from the kernel, if available,
using the functionality added by CL 520266. Note we could not modify
syscall.StartProcess to return pidfd directly because it is a public
API and its callers do not expect it, so we have to use ensurePidfd
and getPidfd.
2. (*Process).Kill: use pidfdSendSignal, if the syscall is available
and pidfd is known. This is slightly more complicated than it should
be, since the syscall can be blocked by e.g. seccomp security policy,
therefore the need for a function to check if it's actually working,
and a soft fallback to kill. Perhaps this precaution is not really
needed.
3. (*Process).Wait: use pidfdWait, if available, otherwise fall back to
using waitid/wait4. This is also more complicated than expected due
to struct siginfo_t idiosyncrasy.
NOTE pidfdSendSignal and pidfdWait are used without a race workaround
(blockUntilWaitable and sigMu, added by CL 23967) because with pidfd,
PID recycle issue doesn't exist (IOW, pidfd, unlike PID, is guaranteed
to refer to one particular process) and thus the race doesn't exist
either.
For #62654.
Updates #13987.
Change-Id: I22ebcc7142b16a3a94c422d2f32504d1a80e8a8f
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/528438
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Back in the day, Wait used to accept options argument.
CL 4962042 fixed the issue of setting process.done flag when WNOHANG
option was used.
Later, CL 5688046 removed options argument from Wait, but did not remove
pid1 != 0 check which was meant to be used with WNOHANG only.
Remove the check, which is useless and also confusing.
Change-Id: I73b9ef4a0dbe35466e659ca58b896d515ba86d02
Reviewed-on: https://go-review.googlesource.com/c/go/+/543736
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
For #58141
Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I52e3e161f81dcbe8605570e47d732992979c4d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/479623
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
|
|
For #20322
For #51572
Change-Id: Id0b4799d097d01128e98ba4cc0092298357bca45
Reviewed-on: https://go-review.googlesource.com/c/go/+/389935
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
|
|
When these packages are released as part of Go 1.18,
Go 1.16 will no longer be supported, so we can remove
the +build tags in these files.
Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs
as defined in src/cmd/dist/buildtool.go, which need to continue
to build with Go 1.4 for now.
Also reverted src/vendor and src/cmd/vendor, which will need
to be updated in their own repos first.
Manual changes in runtime/pprof/mprof_test.go to adjust line numbers.
For #41184.
Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/344955
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294430
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Exposes ErrProcessDone variable in windows and plan9
also returns this error code instead of
errors.New("os: process already finished")
Fixes #42311
Change-Id: Ie807b6526e7b6c27636e6bffe5ff0c904b319be4
GitHub-Last-Rev: 2153e0d7020d8ee9e94087d02977ea049b7fd6a0
GitHub-Pull-Request: golang/go#42313
Reviewed-on: https://go-review.googlesource.com/c/go/+/266997
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
|
|
(*Process).Signal returns an error sentinel, previously errFinished,
when (*Process).done or syscall.ESRCH. Callers would like the ability to
test for this state, so the value has been exported as ErrProcessDone.
Fixes #39444
Change-Id: I510e7647cc032af290180de5149f35ab7b09a526
Reviewed-on: https://go-review.googlesource.com/c/go/+/242998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
|
|
Historically we've assumed that we can install all signal handlers
with the SA_RESTART flag set, and let the system restart slow functions
if a signal is received. Therefore, we don't have to worry about EINTR.
This is only partially true, and we've added EINTR checks already for
connect, and open/read on Darwin, and sendfile on Solaris.
Other cases have turned up in #36644, #38033, and #38836.
Also, #20400 points out that when Go code is included in a C program,
the C program may install its own signal handlers without SA_RESTART.
In that case, Go code will see EINTR no matter what it does.
So, go ahead and check for EINTR. We don't check in the syscall package;
people using syscalls directly may want to check for EINTR themselves.
But we do check for EINTR in the higher level APIs in os and net,
and retry the system call if we see it.
This change looks safe, but of course we may be missing some cases
where we need to check for EINTR. As such cases turn up, we can add
tests to runtime/testdata/testprogcgo/eintr.go, and fix the code.
If there are any such cases, their handling after this change will be
no worse than it is today.
For #22838
Fixes #20400
Fixes #36644
Fixes #38033
Fixes #38836
Change-Id: I7e46ca8cafed0429c7a2386cc9edc9d9d47a6896
Reviewed-on: https://go-review.googlesource.com/c/go/+/232862
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
You were a useful port and you've served your purpose.
Thanks for all the play.
A subsequent CL will remove amd64p32 (including assembly files and
toolchain bits) and remaining bits. The amd64p32 removal will be
separated into its own CL in case we want to support the Linux x32 ABI
in the future and want our old amd64p32 support as a starting point.
Updates #30439
Change-Id: Ia3a0c7d49804adc87bf52a4dea7e3d3007f2b1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/199499
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This commit adds AIX operating system to os package for ppc64
architecture.
Updates: #25893
Change-Id: Ieb9a2b3ac5b9abd3b5ab68eb732c17b6256d624d
Reviewed-on: https://go-review.googlesource.com/c/138725
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This commit adds the js/wasm architecture to the os package.
Access to the actual file system is supported through Node.js.
Updates #18892
Change-Id: I6fa642fb294ca020b2c545649d4324d981aa0408
Reviewed-on: https://go-review.googlesource.com/109977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
On systems that support the POSIX.1-2008 waitid function, we can use it
to block until a wait will succeed. This avoids a possible race
condition: if a program calls p.Kill/p.Signal and p.Wait from two
different goroutines, then it is possible for the wait to complete just
before the signal is sent. In that case, it is possible that the system
will start a new process using the same PID between the wait and the
signal, causing the signal to be sent to the wrong process. The
Process.isdone field attempts to avoid that race, but there is a small
gap of time between when wait returns and isdone is set when the race
can occur.
This CL avoids that race by using waitid to wait until the process has
exited without actually collecting the PID. Then it sets isdone, then
waits for any active signals to complete, and only then collects the PID.
No test because any plausible test would require starting enough
processes to recycle all the process IDs.
Update #13987.
Update #16028.
Change-Id: Id2939431991d3b355dfb22f08793585fc0568ce8
Reviewed-on: https://go-review.googlesource.com/23967
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
While we're here, fix the implementation of Release on both
Unix and Windows: Release is supposed to make Signal an error.
While we're here, make sure we never Signal pid 0.
(Don't try this at home.)
Fixes #7658.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/152240043
|
|
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.
|
