From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andres Lagar-Cavilla Subject: [PATCH 8 of 8] x86/mm: Avoid spurious deadlock panic trigger Date: Wed, 25 Jan 2012 22:53:32 -0500 Message-ID: <409f0f368ae3c87f82d6.1327550012@xdev.gridcentric.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca List-Id: xen-devel@lists.xenproject.org xen/arch/x86/mm/mm-locks.h | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) 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 diff -r 2dc0ef05662e -r 409f0f368ae3 xen/arch/x86/mm/mm-locks.h --- 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 ) {