[asterisk-bugs] [Asterisk 0017407]: [patch] DEADLOCK_AVOIDANCE can actually generate dealocks

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17407 
====================================================================== 
Reported By:                pdf
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17407
Category:                   Core/General
Reproducibility:            sometimes
Severity:                   block
Priority:                   normal
Status:                     ready for testing
Target Version:             1.4.33
Asterisk Version:           1.4.31 
JIRA:                       SWP-1584 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-05-27 00:23 CDT
Last Modified:              2010-05-27 09:49 CDT
====================================================================== 
Summary:                    [patch] DEADLOCK_AVOIDANCE can actually generate
dealocks
Description: 
We have reported this issue to Digium support, however were asked to submit
the patch via this tracker.

In brief: the DEADLOCK_AVOIDANCE macro attempts to release an existing
lock, then relock after a usleep(1), to allow other code to proceed around
the lock.  However, it doesn't actually check to see if a lock was released
by the unlock, before taking a new lock.  This means that whenever there is
no lock released, a new lock is taken that will never be released, meaning
that DEADLOCK_AVOIDANCE actually leaks locks, which can obviously lead to a
deadlock.
====================================================================== 

---------------------------------------------------------------------- 
 (0122559) davidw (reporter) - 2010-05-27 09:49
 https://issues.asterisk.org/view.php?id=17407#c122559 
---------------------------------------------------------------------- 
This is papering over the cracks.  It is a pre-condition of using this
macro that you do own the lock.

The overall intent is that you end up owning all the relevant locks.

If you can reproduce this condition without modifying the code, you need
to fix the logic that allows a path to this call without successively
gaining the lock. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-27 09:49 davidw         Note Added: 0122559                          
======================================================================