summaryrefslogtreecommitdiff
path: root/contrib/init.d/rc.suse.asterisk
diff options
context:
space:
mode:
authorMark Michelson <mmichelson@digium.com>2008-03-14 16:52:51 +0000
committerMark Michelson <mmichelson@digium.com>2008-03-14 16:52:51 +0000
commit086d4f0e56ab261fd364ca0bba56eebd0b3ea096 (patch)
tree2f366ac5dd43c728e3aa8d6e549988ea1ea739af /contrib/init.d/rc.suse.asterisk
parent71e3883f9f978f69c52b30b7dff754b0d1a18325 (diff)
Merged revisions 108737 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r108737 | mmichelson | 2008-03-14 11:44:08 -0500 (Fri, 14 Mar 2008) | 33 lines Fix a race condition in the SIP packet scheduler which could cause a crash. chan_sip uses the scheduler API in order to schedule retransmission of reliable packets (such as INVITES). If a retransmission of a packet is occurring, then the packet is removed from the scheduler and retrans_pkt is called. Meanwhile, if a response is received from the packet as previously transmitted, then when we ACK the response, we will remove the packet from the scheduler and free the packet. The problem is that both the ACK function and retrans_pkt attempt to acquire the same lock at the beginning of the function call. This means that if the ACK function acquires the lock first, then it will free the packet which retrans_pkt is about to read from and write to. The result is a crash. The solution: 1. If the ACK function fails to remove the packet from the scheduler and the retransmit id of the packet is not -1 (meaning that we have not reached the maximum number of retransmissions) then release the lock and yield so that retrans_pkt may acquire the lock and operate. 2. Make absolutely certain that the ACK function does not recursively lock the lock in question. If it does, then releasing the lock will do no good, since retrans_pkt will still be unable to acquire the lock. (closes issue #12098) Reported by: wegbert (closes issue #12089) Reported by: PTorres Patches: 12098-putnopvutv3.patch uploaded by putnopvut (license 60) Tested by: jvandal ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'contrib/init.d/rc.suse.asterisk')
0 files changed, 0 insertions, 0 deletions