| 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 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_local |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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+ | ||