[asterisk-dev] [Code Review] Deadlock avoidance for dahdi_indicate, dadhi_indicate and dahdi_hangup

Russell Bryant russell at digium.com
Wed Jun 23 13:19:26 CDT 2010


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/738/#review2254
-----------------------------------------------------------



trunk/channels/chan_dahdi.c
<https://reviewboard.asterisk.org/r/738/#comment4762>

    When an ast_channel_tech callback is called from within the context of the channel thread with the ast_channel locked, it is (supposed to be) safe to directly lock the associated channel pvt struct.  That is the defined locking order for Asterisk channels.
    
    If this code locked up with another thread acquiring the locks in the opposite order, then it is the other thread that must be changed to yield the pvt when working to acquire the ast_channel lock.
    
    There is some additional information about deadlock avoidance in Asterisk (including the specific case of ast_channel vs. pvt) in the doc/CODING-GUIDELINES document.


- Russell


On 2010-06-23 05:14:39, Alec Davis wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/738/
> -----------------------------------------------------------
> 
> (Updated 2010-06-23 05:14:39)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Deadlock between dahdi_exception and dahdi_indicate when callwaiting is enabled on an TDM800P FXS port.
> After initial deadlock was resolved, experienced deadlock with dahdi_hangup 
> 
> 
> This addresses bug 16847.
>     https://issues.asterisk.org/view.php?id=16847
> 
> 
> Diffs
> -----
> 
>   trunk/channels/chan_dahdi.c 270075 
> 
> Diff: https://reviewboard.asterisk.org/r/738/diff
> 
> 
> Testing
> -------
> 
> Using SVN-trunk-r272052M
> Multiple calls from 2line SIP phone.
> I also observed same deadlock under exactly the same test conditions with 1.6.0, 1.6.1 and 1.6.2
> Didn't test asterisk 1.4 
> 
> 
> Thanks,
> 
> Alec
> 
>




More information about the asterisk-dev mailing list