[asterisk-bugs] [Asterisk 0015911]: Deadlock in channel masquerade handling

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15911 
====================================================================== 
Reported By:                russell
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15911
Category:                   Core/Channels
Reproducibility:            have not tried
Severity:                   block
Priority:                   normal
Status:                     confirmed
Target Version:             1.6.2.0
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 219302 
Request Review:              
====================================================================== 
Date Submitted:             2009-09-17 15:50 CDT
Last Modified:              2009-09-17 15:55 CDT
====================================================================== 
Summary:                    Deadlock in channel masquerade handling
Description: 
In Asterisk trunk and 1.6.2, ast_channels are stored in an astobj2
container, instead of a singly linked list as before.  The hash value is
based on the channel name.  So, during a masquerade, when the channel name
changes, the channel must be removed and reinserted into the hash table
using its new hash value.

This change introduced locking of the channels container where it did not
exist before.  Specifically, it introduces locking in the order of 1) the
ast_channel, and 2) the container.

Many other places in the code use the locking order 1) ast_channel
container, 2) channels, and this is the locking order that must be obeyed.

Some work needs to be put into masquerade handling to resolve this
deadlock and get it to follow the proper locking order.
====================================================================== 

---------------------------------------------------------------------- 
 (0110901) russell (administrator) - 2009-09-17 15:55
 https://issues.asterisk.org/view.php?id=15911#c110901 
---------------------------------------------------------------------- 
I observed a deadlock caused by this problem earlier today when someone was
working on SIP transfers.  The device state processing thread had locked
the container and wanted the channel lock.  The SIP monitor thread
processing a transfer held a channel lock and was trying to complete a
masquerade, and was waiting on the container lock. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-17 15:55 russell        Note Added: 0110901                          
======================================================================