(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
1.4
Russell Bryant 18 years ago
parent cd304a0a76
commit f6212e48cb

@ -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));

Loading…
Cancel
Save