|Summary:||ASTERISK-17191: [patch] p->owner unregistered from module prematurely in local_hangup.|
|Reporter:||David Woolley (davidw)||Labels:|
|Date Opened:||2010-12-30 11:09:27.000-0600||Date Closed:||2015-03-13 21:17:11|
|Environment:||Attachments:||( 0) Issue18561-patch1.diff.txt|
|Description:||r 259899 introduces deadlock avoidance for p->owner. This is done after p->owner is unregistered from the module. The equivalent code for p->chan does the unregister immediately adjacent to the nulling, when all the locks have been obtained.|
****** ADDITIONAL INFORMATION ******
It seems to me that a colliding hangup for the two ends of the local channel could result in a double unregister, as well as any other risks from a premature unregister.
The nulling was introduced later, although I don't believe that nulling is essential for this issue.
This was noted during a code review of interacting changes prior to backporting r 292867.
Severity reflects lack of confirmed observations in the field, rather than the worst case possible effect.
See also ASTERISK-17188
r 259899 corresponds to ASTERISK-15958
|Comments:||By: David Woolley (davidw) 2011-01-05 09:00:38.000-0600|
I've uploaded a patch which moves the module_user_remove to a safer place.
This patch overlaps with the patch for ASTERISK-17188, but I've created it as though that had not been applied. If you do try to apply both, you will get a match with fuzz, if you apply this second. If you apply it first, there may be fuzz, or it might not take.
Note, I don't like the idea of removing the reference counts within the referenced module, but we don't unload it, except at shutdown.
By: Joshua C. Colp (jcolp) 2015-03-13 21:17:11.337-0500
This is no longer an issue in 1.8+