x86/mm: Avoid spurious deadlock panic trigger

In the mm layer, if we take lock A, then lock B, and the recursively lock A,
the deadlock detector panics. This is not a deadlock risk because we
already 'own' the outer lock (A), so we will not contend for that resource.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>

diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 43dade2b90afba06bf0f81e3317d93e8af4d8b58..9f8413d2b0b04a29c6ed62da35606bc61e34572e 100644 (file)
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -61,7 +61,8 @@ do {                                \
 
 static inline void _mm_lock(mm_lock_t *l, const char *func, int level, int rec)
 {
-    __check_lock_level(level);
+    if ( !((mm_locked_by_me(l)) && rec) ) 
+        __check_lock_level(level);
     spin_lock_recursive(&l->lock);
     if ( l->lock.recurse_cnt == 1 )
     {