cameraserver: fix deadlock scenario in torchModeStatusChanged callback.
The following scenario can occur:
T1: CameraService::connectDevice()
CameraService::connectDeviceHelper()
CameraProviderManager::openSession() ---> holds mInterfaceLock
.
.
. on the same thread before openSession execution completes
CameraProviderManager::ProviderInfo::torchModeStatusChange() callback from HAL
.
CameraService::onTorchStatusChanged()
CameraProviderManager::getSystemCameraKind tries to lock mInterfaceLock -> deadlock.
We now pass in system camera kind to onTorchStatusChanged in
CameraProviderManager::torchModeStatusChange() instead of calling getSystemCameraKind
This CL also removes CameraProviderManager::mStatusListenerMutex, since
it wasn't protecting any data structure.
Bug: 202198748
Test: camera CTS, GCA (basic validity)
Change-Id: Id95a2aa061b6cb4db4a25b1a2aa6a390f898af87
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
diff --git a/services/camera/libcameraservice/common/CameraProviderManager.h b/services/camera/libcameraservice/common/CameraProviderManager.h
index e3763a1..fdb2673 100644
--- a/services/camera/libcameraservice/common/CameraProviderManager.h
+++ b/services/camera/libcameraservice/common/CameraProviderManager.h
@@ -155,6 +155,9 @@
const String8 &physicalCameraId,
hardware::camera::common::V1_0::CameraDeviceStatus newStatus) = 0;
virtual void onTorchStatusChanged(const String8 &cameraId,
+ hardware::camera::common::V1_0::TorchModeStatus newStatus,
+ SystemCameraKind kind) = 0;
+ virtual void onTorchStatusChanged(const String8 &cameraId,
hardware::camera::common::V1_0::TorchModeStatus newStatus) = 0;
virtual void onNewProviderRegistered() = 0;
};
@@ -329,8 +332,6 @@
// All private members, unless otherwise noted, expect mInterfaceMutex to be locked before use
mutable std::mutex mInterfaceMutex;
- // the status listener update callbacks will lock mStatusMutex
- mutable std::mutex mStatusListenerMutex;
wp<StatusListener> mListener;
ServiceInteractionProxy* mServiceProxy;