(closes issue #9724, closes issue #10374)

Reported by: kenw
Patches:
      9724.txt uploaded by russell (license 2)
Tested by: kenw, russell

Resolve a deadlock that occurs when doing a SIP transfer to parking.

I come across this type of deadlock fairly often it seems.  It is very important
to mind the boundary between the channel driver and the core in respect to the
channel lock and the channel-pvt lock.  Channel drivers lock to lock the
pvt and then the channel once it calls into the core, while the core will do
it in the opposite order.  The way this is avoided is by having channel drivers
either release their pvt lock while calling into the core, or such as in this
case, unlocking the pvt just long enough to acquire the channel lock.

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81832 65c4cc65-6c06-0410-ace0-fbb531ad65f3

diff --git a/channels/chan_sip.c b/channels/chan_sip.c
index b31d456c13f7172e09823f1bec9a273fe057c413..d449102519e6aac61378b87b39f0b7ed744962b7 100644 (file)
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -12873,8 +12873,17 @@ static int sip_park(struct ast_channel *chan1, struct ast_channel *chan2, struct
        transferer->readformat = chan2->readformat;
        transferer->writeformat = chan2->writeformat;
 
-       /* Prepare for taking over the channel */
+       /* Prepare for taking over the channel.  Go ahead and grab this channel
+        * lock here to avoid a deadlock with callbacks into the channel driver
+        * that hold the channel lock and want the pvt lock.  */
+       while (ast_channel_trylock(chan2)) {
+               struct sip_pvt *pvt = chan2->tech_pvt;
+               ast_mutex_unlock(&pvt->lock);
+               usleep(1);
+               ast_mutex_lock(&pvt->lock);
+       }
        ast_channel_masquerade(transferer, chan2);
+       ast_channel_unlock(chan2);
 
        /* Setup the extensions and such */
        ast_copy_string(transferer->context, chan2->context, sizeof(transferer->context));