[asterisk-bugs] [Asterisk 0014705]: [patch] Deadlock when manipulating module_list over AMI and CLI

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14705 
====================================================================== 
Reported By:                jamessan
Assigned To:                tilghman
====================================================================== 
Project:                    Asterisk
Issue ID:                   14705
Category:                   Core/ManagerInterface
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     ready for review
Asterisk Version:           1.4.22 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-19 13:36 CDT
Last Modified:              2009-04-09 13:08 CDT
====================================================================== 
Summary:                    [patch] Deadlock when manipulating module_list over
AMI and CLI
Description: 
AMI "Action: Command" commands funnel through ast_cli_command as do actual
commands from the cli.  The difference being that when the command is
initiated from the AMI, process_message is holding the actionlock before
ast_cli_command is called.

A "module reload" command from the AMI first locks actionlock
(process_message)  and then locks the module_list (ast_module_reload).
A "module load"/"module unload" command from the CLI first locks the
module_list (ast_load_resource/ast_unload_resource) and then locks
actionlock (ast_manager_register*/ast_manager_unregister).

Therefore a properly timed "module load"/"module unload" issued from the
CLI and a "module reload" from the AMI can cause the AMI and CLI threads to
deadlock.

Releasing actionlock in process_message as soon as we find the command we
need to run is, unfortunately, not a viable solution.  If the AMI thread
were to get interrupted just after releasing the lock but before calling
the function it found, that could be removed out from under us by a CLI
command.

It would seem that blacklisting all module commands from the AMI, instead
of purely ones that would have the potential to modify the manager_action
list is the only surefire fix.
====================================================================== 

---------------------------------------------------------------------- 
 (0103032) svnbot (reporter) - 2009-04-09 13:08
 http://bugs.digium.com/view.php?id=14705#c103032 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 187428

U   branches/1.4/include/asterisk/lock.h
U   branches/1.4/main/manager.c

------------------------------------------------------------------------
r187428 | tilghman | 2009-04-09 13:08:21 -0500 (Thu, 09 Apr 2009) | 8
lines

Race condition between ast_cli_command() and 'module unload' could cause a
deadlock.
Add lock timeouts to avoid this potential deadlock.
(closes issue http://bugs.digium.com/view.php?id=14705)
 Reported by: jamessan
 Patches: 
       20090320__bug14705.diff.txt uploaded by tilghman (license 14)
 Tested by: jamessan

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=187428 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-09 13:08 svnbot         Checkin                                      
2009-04-09 13:08 svnbot         Note Added: 0103032                          
======================================================================