fix: protect cidrMap with lock#98
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: iamjaeholee 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 |
|
Welcome @iamjaeholee! |
Add lock/unlock around rangeAllocator.cidrMap accesses in TestMultiCIDRAllocateOrOccupyCIDRSuccess, TestMultiCIDRAllocateOrOccupyCIDRFailure, and TestMultiCIDRReleaseCIDRSuccess to satisfy the protectedby linter.
Private helper functions that access cidrMap now receive it as a parameter instead of accessing r.cidrMap directly. Lock-holding callers (AllocateOrOccupyCIDR, ReleaseCIDR, reconcileCreate, reconcileBootstrap, reconcileDelete, NewMultiCIDRRangeAllocator) pass r.cidrMap within their lock scope, satisfying the protectedby linter without introducing deadlocks.
d06b80b to
91c6f7b
Compare
| // lock guards cidrMap to avoid races in CIDR allocation. | ||
| lock *sync.Mutex | ||
| // cidrMap maps ClusterCIDR labels to internal ClusterCIDR objects. | ||
| // cidrMap maps ClusterCIDR labels to internal ClusterCIDR objects. Protected by lock. |
There was a problem hiding this comment.
I don't think this comment is necessary.
|
|
||
| // occupyCIDRs marks node.PodCIDRs[...] as used in allocator's tracked cidrSet. | ||
| func (r *multiCIDRRangeAllocator) occupyCIDRs(logger klog.Logger, node *corev1.Node) error { | ||
| func (r *multiCIDRRangeAllocator) occupyCIDRs(logger klog.Logger, node *corev1.Node, cidrMap map[string][]*cidrset.ClusterCIDR) error { |
There was a problem hiding this comment.
A comment on these functions would be more useful, to point out that access to cidrMap should be protected by a lock before passing in for this and the similar functions below.
There was a problem hiding this comment.
I think so too. i will make a comment on the functions
|
I also wonder if it would be better to just use |
Remove "Protected by lock." from cidrMap field comment since the locking semantics are now documented on each function that accesses cidrMap. Add "requires the caller to hold r.lock" comments to all private helper functions that accept cidrMap as a parameter.
|
Thanks for the suggestion! I think keeping the mutex approach makes more sense here. The map values are slices |
|
Updates look good - thanks! /lgtm |
What this PR does / why we need it
Fixes concurrent access to
multiCIDRRangeAllocator.cidrMapthat was not protected bylock.Closes #86
Changes
Protected by lock.comment to thecidrMapfield declaration as requested in the issue.lock.Lock()/lock.Unlock()aroundcidrMapaccesses inNewMultiCIDRRangeAllocatorthat were identified as unprotected by theprotectedbylinter.TestSyncClusterCIDRDeleteWithNodesAssociated,TestMultiCIDRSetDataRace) for consistent and race-free access.How to verify
Run the
protectedbylinter to confirm no unprotected accesses remain:Run tests with the race detector:
go test -race ./pkg/controller/ipam/...