Camera: Avoid possible race condition during provider init
The current sequence of registering for provider notifications
and trying to add a legacy provider could introduce a race
condition leading to a deadlock. The "onRegistration" callback
will try to acquire "mInterfaceMutex" which is still held during
the execution of "addProvider" for legacy. However "addProvider"
could get suspended waiting on the HIDL provider interface. If this
happens and the same thread that unblocks the service query tries
to notify the provider manager, then we will end up in a deadlock.
To avoid this, the initialization sequence can be modified a bit.
First add the legacy provider and then register for notifications.
Bug: 35096594
Test: Manual using stop/start of cameraserver
Change-Id: Ia381ae6bf567525cabd3f51246a192ddac37b7f8
diff --git a/services/camera/libcameraservice/common/CameraProviderManager.cpp b/services/camera/libcameraservice/common/CameraProviderManager.cpp
index 51b31df..c40809f 100644
--- a/services/camera/libcameraservice/common/CameraProviderManager.cpp
+++ b/services/camera/libcameraservice/common/CameraProviderManager.cpp
@@ -54,6 +54,9 @@
mListener = listener;
mServiceProxy = proxy;
+ // See if there's a passthrough HAL, but let's not complain if there's not
+ addProvider(kLegacyProviderName, /*expected*/ false);
+
// Registering will trigger notifications for all already-known providers
bool success = mServiceProxy->registerForNotifications(
/* instance name, empty means no filter */ "",
@@ -63,8 +66,7 @@
"about camera providers", __FUNCTION__);
return INVALID_OPERATION;
}
- // See if there's a passthrough HAL, but let's not complain if there's not
- addProvider(kLegacyProviderName, /*expected*/ false);
+
return OK;
}