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

[Asterisk Bug Tracker]

The following issue has been ASSIGNED. 
====================================================================== 
http://bugs.digium.com/view.php?id=14705 
====================================================================== 
Reported By:                jamessan
Assigned To:                lmadsen
====================================================================== 
Project:                    Asterisk
Issue ID:                   14705
Category:                   Core/ManagerInterface
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     ready for testing
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-03 13:36 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.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-03 13:36 tilghman       Assigned To              tilghman => lmadsen 
======================================================================