[asterisk-bugs] [Asterisk 0011609]: Deadlock in pbx/sip introduced by fix for bug 0011323

[noreply at bugs.digium.com]

The following issue has been ASSIGNED. 
====================================================================== 
http://bugs.digium.com/view.php?id=11609 
====================================================================== 
Reported By:                ardjan
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   11609
Category:                   PBX/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.15  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             12-20-2007 09:41 CST
Last Modified:              12-21-2007 10:34 CST
====================================================================== 
Summary:                    Deadlock in pbx/sip introduced by fix for bug
0011323
Description: 
Bug 0011323 was fixed by locking &conlock in ast_hint_state_changed()
(pbx.c). This does fix the mentioned problem, but introduces another
possible deadlock:

The function chain: 
sipsock_read()(chan_sip.c) -> handle_request()(chan_sip.c) ->
handle_request_subscribe()(chan_sip.c) -> ast_extension_state()(pbx.c) ->
ast_hint_extension() (pbx.c)

first locks &p->lock (in find_call() called by sipsock_read()) and later
on locks &conlock in ast_hint_extension().

The function chain:
ast_hint_state_changed()(pbx.c) -> cb_extensionstate()(chan_sip.c)

however now first locks &conlock in ast_hint_state_changed() and then
locks &p->lock in cb_extensionstate().

This results in the situation where, if a device changes state and another
device resubscribes at the same moment, a deadlock can occur (&p->lock will
be the same mutex in both paths in this case). This situation already
occurred on one of our servers where subscribes and notifies are used
heavily.

As far as I can see this problem is fixed in trunk by using read locks, I
guess this would also be nice in the 1.4 branch but I can't really see the
consequences of such a change.


====================================================================== 

---------------------------------------------------------------------- 
 svnbot - 12-21-07 10:34  
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 94466

U   branches/1.4/include/asterisk/pbx.h
U   branches/1.4/main/pbx.c

------------------------------------------------------------------------
r94466 | russell | 2007-12-21 10:34:32 -0600 (Fri, 21 Dec 2007) | 6 lines

Convert the contexts lock to a read/write lock to resolve a deadlock. 
This
has a nice side benefit of improving performance.  :)

(closes issue http://bugs.digium.com/view.php?id=11609)
(closes issue http://bugs.digium.com/view.php?id=11080)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=94466 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-21-07 10:34  svnbot         Note Added: 0075799                          
12-21-07 10:34  svnbot         Status                   new => assigned     
12-21-07 10:34  svnbot         Assigned To               => russell         
======================================================================