Skip to content

Commit

Permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix missing lock around _controllers access. (#28384)
Browse files Browse the repository at this point in the history
The rules for the locking are that we must lock when on the Matter queue, which
is the case in createControllerOnExistingFabric.
bzbarsky-apple authored and pull[bot] committed Dec 21, 2023

Verified

This commit was signed with the committer’s verified signature.
jalaziz Jameel Al-Aziz
1 parent f271226 commit 1035771
Showing 1 changed file with 6 additions and 2 deletions.
8 changes: 6 additions & 2 deletions src/darwin/Framework/CHIP/MTRDeviceControllerFactory.mm
Original file line number Diff line number Diff line change
@@ -96,7 +96,7 @@ @interface MTRDeviceControllerFactory ()
//
// 1) The only mutating accesses to the controllers array happen when the
// current queue is not the Matter queue. This is a good assumption, because
// the implementation of the fucntions that mutate the array do sync dispatch
// the implementation of the functions that mutate the array do sync dispatch
// to the Matter queue, which would deadlock if they were called when that
// queue was the current queue.
// 2) It's our API consumer's responsibility to serialize access to us from
@@ -597,7 +597,11 @@ - (MTRDeviceController * _Nullable)createControllerOnExistingFabric:(MTRDeviceCo
return;
}

for (MTRDeviceController * existing in _controllers) {
os_unfair_lock_lock(&_controllersLock);
NSArray<MTRDeviceController *> * controllersCopy = [_controllers copy];
os_unfair_lock_unlock(&_controllersLock);

for (MTRDeviceController * existing in controllersCopy) {
BOOL isRunning = YES; // assume the worst
if ([existing isRunningOnFabric:fabricTable fabricIndex:fabric->GetFabricIndex() isRunning:&isRunning]
!= CHIP_NO_ERROR) {

0 comments on commit 1035771

Please sign in to comment.