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

Backport of volumewatcher: prevent panic on nil volume into release/1.2.x #15104

Merged

Conversation

hc-github-team-nomad-core
Copy link
Contributor

Backport

This PR is auto-generated from #15101 to be assessed for backporting due to the inclusion of the label backport/1.2.x.

WARNING automatic cherry-pick of commits failed. Commits will require human attention.

The below text is copied from the body of the original PR.


Fixes #15095

If a GC claim is written and then volume is deleted before the volumewatcher enters its run loop, we panic on the nil-pointer access. Simply doing a nil-check at the top of the loop reveals a race condition around shutting down the loop just as a new update is coming in.

Have the parent volumeswatcher send an initial update on the channel before returning, so that we're still holding the lock. Update the watcher's Stop method to set the running state, which lets us avoid having a second context and makes stopping synchronous. This reduces the cases we have to handle in the run loop.

Updated the tests now that we'll safely return from the goroutine and stop the runner in a larger set of cases. Ran the tests with the -race detection flag and fixed up any problems found here as well, and tested this on my local democratic-csi cluster.

@hashicorp-cla
Copy link

hashicorp-cla commented Nov 1, 2022

CLA assistant check
All committers have signed the CLA.

….2.x

volumewatcher: prevent panic on nil volume (#15101)

If a GC claim is written and then volume is deleted before the `volumewatcher`
enters its run loop, we panic on the nil-pointer access. Simply doing a
nil-check at the top of the loop reveals a race condition around shutting down
the loop just as a new update is coming in.

Have the parent `volumeswatcher` send an initial update on the channel before
returning, so that we're still holding the lock. Update the watcher's `Stop`
method to set the running state, which lets us avoid having a second context and
makes stopping synchronous. This reduces the cases we have to handle in the run
loop.

Updated the tests now that we'll safely return from the goroutine and stop the
runner in a larger set of cases. Ran the tests with the `-race` detection flag
and fixed up any problems found here as well.
@tgross tgross force-pushed the backport/b-panic-volumewatcher/smoothly-smart-bluebird branch from 9ab6180 to d35ca17 Compare November 1, 2022 21:01
@tgross tgross merged commit ff968ec into release/1.2.x Nov 1, 2022
@tgross tgross deleted the backport/b-panic-volumewatcher/smoothly-smart-bluebird branch November 1, 2022 21:03
@github-actions
Copy link

github-actions bot commented Mar 2, 2023

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 2, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants