[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-28 05:41 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0122608) davidw (reporter) - 2010-05-28 05:41
 https://issues.asterisk.org/view.php?id=17407#c122608 
---------------------------------------------------------------------- 
I think there are awkward policy questions: one has to balance the risk of
instability, against the loss of service.

However, as an example, you will find that Linux drivers that get
themselves into difficulty deliberately leave the offending process in an
unkillable state, because the resources owned by the process are in an
unknown state, so cannot safely be released.  In this context, the right
approach might be to request the lock, then go into an indefinite sleep.

I think similar provisions go back to early mainframe OSes.

Where this causes difficulty for Asterisk is that I think Asterisk can end
up temporarily locking resources in processing that is not fundamentally
critical to system integrity, typically resulting in the CLI locking out
because of some enquiry operation.  That means that a compromised resource
may result in a complete system lockup, rather than, say, losing just one
device, or call.

If you just log a warning, most people reporting a problem will not
associate it with the problem, especially if it is some way back in the
logs. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-28 05:41 davidw         Note Added: 0122608                          
======================================================================