[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:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.31 
JIRA:                        
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 06:22 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0122553) davidw (reporter) - 2010-05-27 06:22
 https://issues.asterisk.org/view.php?id=17407#c122553 
---------------------------------------------------------------------- 
Isn't failing to unlock an indication of a serious coding error?  Rather
than simply not locking, shouldn't it be outputting an error message.

Also, a deadlock of the resource may well be the safest result, as it has
potentially been corrupted by manipulating it when it was, incorrectly,
assumed to have been locked, and deadlocking it limits the area of damage. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-27 06:22 davidw         Note Added: 0122553                          
======================================================================