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.

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

time, runtime: scheduled timer may never fire if GOMAXPROCS is reduced [1.15 backport] #45731

Closed
gopherbot opened this issue Apr 23, 2021 · 5 comments

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 23, 2021

@ianlancetaylor requested issue #45716 to be considered for backport to the next 1.15 minor release.

@gopherbot Please open backport to 1.15 branch.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 23, 2021

This was already fixed on the 1.16 branch by CL 300610. This issue is to backport that CL to the 1.15 branch as well.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Apr 23, 2021

Change https://golang.org/cl/313130 mentions this issue: [release-branch.go1.15] runtime, time: disable preemption in addtimer

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Apr 23, 2021

Change https://golang.org/cl/313129 mentions this issue: [release-branch.go1.15] runtime, time: disable preemption in addtimer

@toothrot
Copy link
Contributor

@toothrot toothrot commented Apr 29, 2021

Approved. This is a serious issue with no workaround.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Apr 29, 2021

Closed by merging 72ccabc to release-branch.go1.15.

@gopherbot gopherbot closed this Apr 29, 2021
gopherbot pushed a commit that referenced this issue Apr 29, 2021
The timerpMask optimization updates a mask of Ps (potentially)
containing timers in pidleget / pidleput. For correctness, it depends on
the assumption that new timers can only be added to a P's own heap.

addtimer violates this assumption if it is preempted after computing pp.
That G may then run on a different P, but adding a timer to the original
P's heap.

Avoid this by disabling preemption while pp is in use.

Other uses of doaddtimer should be OK:

* moveTimers: always moves to the current P's heap
* modtimer, cleantimers, addAdjustedTimers, runtimer: does not add net
  new timers to the heap while locked

For #44868
Fixes #45731

Change-Id: I4a5d080865e854931d0a3a09a51ca36879101d72
Reviewed-on: https://go-review.googlesource.com/c/go/+/300610
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/313129
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants