[asterisk-bugs] [JIRA] (ASTERISK-25645) res_rtp_asterisk: Lock inversion

[Etienne Lessard (JIRA)]

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

Etienne Lessard commented on ASTERISK-25645:
--------------------------------------------

Hi,

I'm in a situation where we would like to use the fixes for the DTLS negotiation delays that were done for ASTERISK-25614. We are currently using Asterisk 13.10.0 with pjproject 2.5, and we can apply patches to both these softwares if needed.

@Dade, in your 2016-01-04 comment, you said "Patching 2.4.5 to change the pj_timer_heap_schedule_w_grp_lock call to pj_timer_heap_schedule, in the 'on_ice_complete' function of ice_session.c should fix it". Have you tested it / are you using such a patch ? Or have you taken another approach to the problem ?

Another question: currently in Asterisk 13.10.0, the rtp_recvfrom function calls various dtls_* and openssl functions without holding the DTLS lock (&dtls->lock). If we were to reapply the commit https://github.com/asterisk/asterisk/commit/24ae124e4f7310cfa64c187b944b2ffc060da28d on our asterisk but without adding the ast_mutex_lock/unlock in rtp_recvfrom, would this create a worst situation than it currently is in Asterisk 13.10.0 (where no locking is done in that section) ?

Thank you

> res_rtp_asterisk: Lock inversion
> --------------------------------
>
>                 Key: ASTERISK-25645
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25645
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>            Reporter: Steve Davies
>         Attachments: deadlocked_threads.txt, experimental_anti_deadlock, unlock_ice_before_callback
>
>
> Reported by Steve Davies on asterisk-dev:
> commit 5e6b1476a087407a052f007d326c504cfeefebe7
> ASTERISK-25614
> 2 code paths which approximate the following will cause a lock-inversion deadlock:
> approximate call orders are:
> a)
> pj_timer_heap_poll (PJ_LOCK)
> ast_rtp_on_ice_complete
> ast_rtp_instance_set_remote_address
> remote_address_set
> ast_rtp_remote_address_set
> (DTLS_LOCK)
> ...
> b)
> ast_pbx...
> app_dial
> bridge...
> read
> rtp_read
> ...
> __rtp_recvfrom
> (DTLS_LOCK)
> dtls_srtp_check_pending
> __rtp_sendto
> pj_ice_sess_send_data
> (PJ_LOCK)



--
This message was sent by Atlassian JIRA
(v6.2#6252)