diff options
author | Matthew Jordan <mjordan@digium.com> | 2013-03-26 02:30:10 +0000 |
---|---|---|
committer | Matthew Jordan <mjordan@digium.com> | 2013-03-26 02:30:10 +0000 |
commit | 58ee2b7d11891bfb2de1d0346aa660ceb5cad80d (patch) | |
tree | 7faf3ab030c5c602a0280bc68b9599018f5c24c2 /res/res_format_attr_h264.c | |
parent | ec7de8ed97d9da6588fbc7dffbe6527fb8b9c250 (diff) |
Resolve deadlock between SIP registration and channel based functions
In r373424, several reentrancy problems in chan_sip were addressed. As a
result, the SIP channel driver is now properly locking the channel driver
private information in certain operations that it wasn't previously. This
exposed two latent problems either in register_verify or by functions called
by register_verify. This includes:
* Holding the private lock while calling sip_send_mwi_to_peer. This can create
a new sip_pvt via sip_alloc, which will obtain the channel container lock.
This is a locking inversion, as any channel related lock must be obtained
prior to obtaining the SIP channel technology private lock.
Note that this issue was already fixed in Asterisk 11.
* Holding the private lock while calling sip_poke_peer. In the same vein as
sip_send_mwi_to_peer, sip_poke_peer can create a new SIP private, causing
the same locking inversion.
Note that this locking inversion typically occured when CLI commands were run
while a SIP REGISTER request was being processed, as many CLI commands (such
as 'sip show channels', 'core show channels', etc.) have to obtain the channel
container lock.
(issue ASTERISK-21068)
Reported by: Nicolas Bouliane
(issue ASTERISK-20550)
Reported by: David Brillert
(issue ASTERISK-21314)
Reported by: Badalian Vyacheslav
(issue ASTERISK-21296)
Reported by: Gabriel Birke
........
Merged revisions 383863 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 383878 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'res/res_format_attr_h264.c')
0 files changed, 0 insertions, 0 deletions