PatchPanel: fix deadlock when releasing a patch
Commit 1e28aaa6 was incomplete in that it only addressed a potential deadlock
when creating an audio patch but the same problem exists when releasing
an audio patch. This change fixes the release audio patch sequence.
Bug: 276386807
Test: repro steps in the bug
Change-Id: I3615f22d4f0a4060b1397d6639625acbc18fbe86
diff --git a/services/audioflinger/PatchPanel.cpp b/services/audioflinger/PatchPanel.cpp
index d25d46f..d0feba5 100644
--- a/services/audioflinger/PatchPanel.cpp
+++ b/services/audioflinger/PatchPanel.cpp
@@ -735,7 +735,11 @@
/* Disconnect a patch */
status_t AudioFlinger::PatchPanel::releaseAudioPatch(audio_patch_handle_t handle)
-{
+ //unlocks AudioFlinger::mLock when calling ThreadBase::sendReleaseAudioPatchConfigEvent
+ //to avoid deadlocks if the thread loop needs to acquire AudioFlinger::mLock
+ //before processing the release patch request.
+ NO_THREAD_SAFETY_ANALYSIS
+ {
ALOGV("%s handle %d", __func__, handle);
status_t status = NO_ERROR;
@@ -772,7 +776,9 @@
break;
}
}
+ mAudioFlinger.unlock();
status = thread->sendReleaseAudioPatchConfigEvent(removedPatch.mHalHandle);
+ mAudioFlinger.lock();
} else {
status = hwDevice->releaseAudioPatch(removedPatch.mHalHandle);
}
@@ -793,7 +799,9 @@
break;
}
}
+ mAudioFlinger.unlock();
status = thread->sendReleaseAudioPatchConfigEvent(removedPatch.mHalHandle);
+ mAudioFlinger.lock();
} break;
default:
status = BAD_VALUE;