[asterisk-bugs] [JIRA] (ASTERISK-20708) Deadlock in chan_sip on transfer when trying to update redirecting information

[Mark Michelson (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200048#comment-200048 ] 

Mark Michelson commented on ASTERISK-20708:
-------------------------------------------

Good catch. The sip_pvt_unlock() location you added is not quite correct though. If current.chan2 is NULL, then we'll end up returning with p unlocked instead of locked. I believe the proper place to put the sip_pvt_unlock() is just below where the SIP_DEFER_BYE_ON_TRANSFER flag is set.
                
> Deadlock in chan_sip on transfer when trying to update redirecting information
> ------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20708
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20708
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Transfers
>    Affects Versions: 11.0.1
>            Reporter: Mark Michelson
>         Attachments: ASTERISK-20708-2.patch, ASTERISK-20708.patch
>
>
> Issue reported by marv (Tim Ringenbach) in #asterisk-dev
> There is a code path that results in an incorrect locking order between a sip_pvt and its owner channel.
> The problem is that the owner and pvt get unlocked, then the pvt gets relocked and calls change_redirecting_information(), which calls get_rdnis(), which then calls pbx_builtin_setvar_helper() on the pvt's owner.
> A patch is attached that moves where the redirecting updates occur to a place where both the pvt and owner are unlocked so that we can safely lock them in the correct order.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira