Commit 5d7e5151 authored Feb 22, 2017 by Emilian Peev

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

parent 231653e9

services/camera/libcameraservice/common/CameraProviderManager.cpp

+4 −2

Original line number	Diff line number	Diff line
		@@ -54,6 +54,9 @@ status_t CameraProviderManager::initialize(wp<CameraProviderManager::StatusListe
		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 @@ status_t CameraProviderManager::initialize(wp<CameraProviderManager::StatusListe
		"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;
		}