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

runtime: potential deadlock cycle caused by scavenge.lock #34047

Closed
mknyszek opened this issue Sep 3, 2019 · 3 comments
Closed

runtime: potential deadlock cycle caused by scavenge.lock #34047

mknyszek opened this issue Sep 3, 2019 · 3 comments
Assignees
Milestone

Comments

@mknyszek
Copy link
Contributor

@mknyszek mknyszek commented Sep 3, 2019

scavenge.lock in the runtime is in a lock cycle with several different locks, all because it may be acquired (and according to the runtime documentation, must!) after the heap lock is acquired.

While the chance for deadlock is incredibly low because it could only happen as the result of an errant stack growth (which takes the slow path), or a rare allocation in the timer code, or in a rare acquisition of sched.lock in ready(), this is nonetheless a regression in stability and we should remove the potential for this lock cycle.

I propose we simply move the scavenger-waking code out of gcPaceScavenger and into its own function which is then called after gcSetTriggerRatio where appropriate. There are only two callsites, so this should be no problem to do.

@mknyszek mknyszek self-assigned this Sep 3, 2019
@mknyszek mknyszek added this to the Go1.14 milestone Sep 3, 2019
@gopherbot
Copy link

@gopherbot gopherbot commented Sep 3, 2019

Change https://golang.org/cl/191977 mentions this issue: runtime: fix lock acquire cycles related to scavenge.lock

@mknyszek
Copy link
Contributor Author

@mknyszek mknyszek commented Sep 6, 2019

This has the potential for reduced stability in Go 1.13. While the chance of deadlock is extremely low, when it hits you it will tend to hit you consistently, because stack depth is consistent (for example #32105).

CC @aclements

@gopherbot Please open a backport issue for 1.13.

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 6, 2019

Backport issue(s) opened: #34150 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

@gopherbot gopherbot closed this in 62e4156 Sep 26, 2019
@golang golang locked and limited conversation to collaborators Sep 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.