stasis/control: Fix possible deadlock with swap channel

If an error occurs during a bridge impart it's possible that
the "bridge_after" callback might try to run before
control_swap_channel_in_bridge has been signalled to continue.
Since control_swap_channel_in_bridge is holding the control lock
and the callback needs it, a deadlock will occur.

* control_swap_channel_in_bridge now only holds the control
  lock while it's actually modifying the control structure and
  releases it while the bridge impart is running.
* bridge_after_cb is now tolerant of impart failures.

Change-Id: Ifd239aa93955b3eb475521f61e284fcb0da2c3b3
This commit is contained in:
George Joseph
2017-09-01 04:17:02 -06:00
committed by Richard Mudgett
parent 9a366d2424
commit 186ef1a657
4 changed files with 94 additions and 62 deletions

View File

@@ -45,6 +45,8 @@ enum ast_bridge_after_cb_reason {
AST_BRIDGE_AFTER_CB_REASON_DEPART,
/*! Was explicitly removed by external code. */
AST_BRIDGE_AFTER_CB_REASON_REMOVED,
/*! The channel failed to enter the bridge. */
AST_BRIDGE_AFTER_CB_REASON_IMPART_FAILED,
};
/*!