[cinder-csi-plugin] Protect OsInstances global map with mutex#3123
[cinder-csi-plugin] Protect OsInstances global map with mutex#3123hemna wants to merge 1 commit into
Conversation
The OsInstances map is accessed from both CreateOpenStackProvider (write) and GetOpenStackProvider (read) without synchronization. Although current usage is single-threaded at startup, this is a latent data race if the driver is ever accessed concurrently. Add a sync.Mutex to guard read and write access to the OsInstances map, preventing potential concurrent map access panics. Signed-off-by: Walter Boring <waboring@hemna.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @hemna. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/ok-to-test |
What this PR does / why we need it:
The
OsInstancesmap is accessed from bothCreateOpenStackProvider(write) andGetOpenStackProvider(read) without synchronization. Although current usage is single-threaded at startup, this is a latent data race that would cause a runtime panic (concurrent map read and map write) if the driver is ever accessed concurrently.This adds a
sync.Mutexto guard read and write access to theOsInstancesmap.Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:
The mutex is intentionally a simple
sync.Mutexrather thansync.RWMutexsince write contention is negligible (only at startup). The lock is held for the minimum scope needed around map access, not around the fullCreateOpenStackProvidercall to avoid holding the lock during network I/O.Release note: