[asterisk-dev] [Code Review] Fix deadlock between subscription event RWLOCK and dialogs container lock in chan_sip. (simplified)
schmidts
reviewboard at asterisk.org
Thu Nov 3 16:13:56 CDT 2011
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1564/#review4675
-----------------------------------------------------------
for me this looks fine, except this small thing see below. But i want to wait for david vossel if he has to say something about this ;)
/branches/1.8/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1564/#comment8867>
i prefer move the iter block above the callback for the dialog container.
with this you can make sure that there will not be a lock enabled before deleting the dialog. normally it takes between 1 ms to max. 1000 ms to come back here so this should be fast enough.
btw i think checking if dialogs_needdestroy container is empty should be faster than an iterator_init to an empty container and this will happens most of the time.
- schmidts
On Nov. 3, 2011, 3:14 p.m., rmudgett wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1564/
> -----------------------------------------------------------
>
> (Updated Nov. 3, 2011, 3:14 p.m.)
>
>
> Review request for Asterisk Developers, David Vossel and schmidts.
>
>
> Summary
> -------
>
> Timing between dialog destruction and a MWI event sending a message could result in a deadlock.
>
> Order of events causing deadlock:
>
> 1a) The event subscription system calls the registered callbacks with its list RWLOCK held.
> 1b) The SIP monitor checks for dialogs needing destruction. It does an ao2_callback that holds the dialogs container lock while searching for dialogs to destroy.
> 2a) The event subscription SIP callback needs to create a temporary dialog to send out the MWI notification. That temporary dialog needs to be inserted in the dialogs container so it must wait.
> 2b) The dialog search finds a dialog to destroy and as a result releases the last reference for a peer. The peer destructor attempts to get the subscription RWLOCK but must wait.
> 3) deadlock
>
>
> This is based off of the original diff posted for review: https://reviewboard.asterisk.org/r/1557/
>
> It directly addresses the comment dvossel posted to the original diff of https://reviewboard.asterisk.org/r/1557/
>
>
> This addresses bug ASTERISK-18747.
> https://issues.asterisk.org/jira/browse/ASTERISK-18747
>
>
> Diffs
> -----
>
> /branches/1.8/channels/chan_sip.c 343338
>
> Diff: https://reviewboard.asterisk.org/r/1564/diff
>
>
> Testing
> -------
>
> It compiles. :)
>
>
> Thanks,
>
> rmudgett
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111103/130558dc/attachment-0001.htm>
More information about the asterisk-dev
mailing list