[asterisk-bugs] [Asterisk 0018165]: [patch] hint state changes deadlock problem

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18165 
====================================================================== 
Reported By:                antonio
Assigned To:                jpeeler
====================================================================== 
Project:                    Asterisk
Issue ID:                   18165
Category:                   Core/PBX
Reproducibility:            have not tried
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.2.13 
JIRA:                       SWP-2495 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-10-19 13:45 CDT
Last Modified:              2010-11-11 13:31 CST
====================================================================== 
Summary:                    [patch] hint state changes deadlock problem
Description: 
What happens is there are two threads that lock resources in a different
order causing a deadlock.

The threads are:

1. from taskprocessor handle_statechange() is called. This one locks
ast_rdlock_contexts, and then eventually call cb_extensionstate() which
immediately does a sip_pvt_lock()

2. do_monitor calls sipsock_read() which calls handle_request_do() which
calls find_call(), which does a sip_pvt_lock() too. The incoming request is
a subscription, so it calls ast_get_hint(), which calls
ast_hint_extension() which calls ast_rdlock_contexts(). Deadlock.

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0018205 PBX hangup
has duplicate       0018260 Asterisk stop processing any SIP request
====================================================================== 

---------------------------------------------------------------------- 
 (0128790) svnbot (reporter) - 2010-11-11 13:31
 https://issues.asterisk.org/view.php?id=18165#c128790 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 294639

_U  branches/1.6.2/
U   branches/1.6.2/include/asterisk.h
U   branches/1.6.2/main/asterisk.c
U   branches/1.6.2/main/pbx.c

------------------------------------------------------------------------
r294639 | jpeeler | 2010-11-11 13:31:01 -0600 (Thu, 11 Nov 2010) | 53
lines

Merged revisions 294384 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r294384 | jpeeler | 2010-11-09 11:37:59 -0600 (Tue, 09 Nov 2010) | 47
lines
  
  Fix a deadlock in device state change processing.
  
  Copied from some notes from the original author (Russell):
  
  Deadlock scenario:
  Thread 1: device state change thread
    Holds - rdlock on contexts
    Holds - hints lock
    Waiting on channels container lock
  
  Thread 2: SIP monitor thread
    Holds the "iflock"
    Holds a sip_pvt lock
    Holds channel container lock
    Waiting for a channel lock
  
  Thread 3: A channel thread (chan_local in this case)
    Holds 2 channel locks acquired within app_dial
    Holds a 3rd channel lock it got inside of chan_local
    Holds a local_pvt lock
    Waiting on a rdlock of the contexts lock
  
  A bunch of other threads waiting on a wrlock of the contexts lock
  
  
  To address this deadlock, some locking order rules must be put in place
and
  enforced. Existing relevant rules:
  
  1) channel lock before a pvt lock
  2) contexts lock before hints lock
  3) channels container before a channel
  
  What's missing is some enforcement of the order when you involve more
than any
  two. To fix this problem, I put in some code that ensures that (at least
in the
  code paths involved in this bug) the locks in (3) come before the locks
in (2).
  To change the operation of thread 1 to comply, I converted the storage
of hints
  to an astobj2 container. This allows processing of hints without holding
the
  hints container lock. So, in the code path that led to thread 1's state,
it no
  longer holds either the contexts or hints lock while it attempts to lock
the
  channels container.
  
  (closes issue https://issues.asterisk.org/view.php?id=18165)
  Reported by: antonio
  
  ABE-2583
........

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

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

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-11 13:31 svnbot         Note Added: 0128790                          
======================================================================