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

David Vossel reviewboard at asterisk.org
Thu Feb 10 14:59:03 CST 2011

This is an automatically generated e-mail. To reply, visit:

Review request for Asterisk Developers.


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.


  trunk/channels/chan_sip.c 307433 

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


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



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

More information about the asterisk-dev mailing list