[asterisk-dev] [Code Review] sip deadlock fix in handle_request_do

[David Vossel]

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

Review request for Asterisk Developers.


Summary
-------

In chan_sip's handle_request_do() function we have to lock both the pvt and the channel at the same time. This involves deadlock avoidance and is a mess. After a number of locking attempts fail on the channel, the request is queued to be handled at a later time. This would typically only occur under very heavy load.

Queued requests are also handled in the handle_request_do() function. Once both a pvt and a channel are locked, the queued requests are handled first, and then the actual request triggering the handle_request_do function's invocation is processed... This is where the problem is.

Between process_request_queue() and calling handle_incoming() the channel may be unlocked. We can detect this by inspecting the nounlock variable which is passed to process_request_queue() but we do not. If the channel remains unlocked entering handle_incoming(), it is very possible a deadlock will occur since many of the code paths in handle_incoming will try to grab a recursive channel lock using the channel API.

This patch detects when the channel has been unlocked during handle_request_do() and attempts to grab the lock again before processing more requests for that dialog.


This addresses bug 18690.
    https://issues.asterisk.org/view.php?id=18690


Diffs
-----

  trunk/channels/chan_sip.c 307433 

Diff: https://reviewboard.asterisk.org/r/1100/diff


Testing
-------

Load tested with 30+ calls a second, verified deadlock does not occur with patch.


Thanks,

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110210/001f9e33/attachment.htm>