CameraService: Disconnect: Release mutex while waiting for joins.

The threads shutting down may have callpaths that require taking the
binder interface mutex, so waiting to join them with that mutex held
can lead to deadlocks.

A specific instance is StreamingProcessor calling dataCallbackTimestamp,
which can immediately lead to a Camera2Client::releaseRecordingFrame call,
which requires the binder interface mutex. If this call happens right when
shutdown is occurring, and Camera2Client::disconnect is holding the mutex,
deadlock ensues.

Bug: 17997578
Change-Id: I71253cd5542b5920ad205976d315110ca0043d94

diff --git a/services/camera/libcameraservice/api1/Camera2Client.cpp b/services/camera/libcameraservice/api1/Camera2Client.cpp
index 2a6aa7b..f3a88a1 100644 (file)
--- a/services/camera/libcameraservice/api1/Camera2Client.cpp
+++ b/services/camera/libcameraservice/api1/Camera2Client.cpp
@@ -419,12 +419,20 @@ void Camera2Client::disconnect() {
 
     ALOGV("Camera %d: Waiting for threads", mCameraId);
 
-    mStreamingProcessor->join();
-    mFrameProcessor->join();
-    mCaptureSequencer->join();
-    mJpegProcessor->join();
-    mZslProcessorThread->join();
-    mCallbackProcessor->join();
+    {
+        // Don't wait with lock held, in case the other threads need to
+        // complete callbacks that re-enter Camera2Client
+        mBinderSerializationLock.unlock();
+
+        mStreamingProcessor->join();
+        mFrameProcessor->join();
+        mCaptureSequencer->join();
+        mJpegProcessor->join();
+        mZslProcessorThread->join();
+        mCallbackProcessor->join();
+
+        mBinderSerializationLock.lock();
+    }
 
     ALOGV("Camera %d: Deleting streams", mCameraId);