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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11609 
====================================================================== 
Reported By:                ardjan
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11609
Category:                   PBX/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
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 04:49 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.


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

---------------------------------------------------------------------- 
 oej - 12-21-07 04:49  
---------------------------------------------------------------------- 
Thanks for a good bug report. We need to find a way to avoid this
situation. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-21-07 04:49  oej            Note Added: 0075787                          
======================================================================