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

[Dade Brandon (JIRA)]

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

Dade Brandon commented on ASTERISK-25645:
-----------------------------------------

Briefly looking at the code from github/asterisk/pjproject HEAD, I think the problem would stem from pj_timer_heap_schedule_w_grp_lock at ice_session.c:1261 - this is where the on_ice_complete callback is scheduled in a timer.  Previously, locking would not occur around the callback's execution, this timer used to instead get scheduled by pj_timer_heap_schedule, which I think is correct- potentially someone became overzealous when creating their group lock architecture.  I don't think the group lock should be used there since 

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

Where that leaves this particular issue then is determining whether to expect users to update their dynamically linked pjproject on 13 vs reverting the dtls negotiation delay patches.  I suggest patching it on github/asterisk/pjproject, and holding 24ae124e4 and 965a0eee from 13 for a few months to give people a chance to upgrade, while leaving it on 11 as 11 is unaffected.

> 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
>
>
> 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)