Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756858Ab1DHNU6 (ORCPT ); Fri, 8 Apr 2011 09:20:58 -0400 Received: from mtoichi13.ns.itscom.net ([219.110.2.183]:64108 "EHLO mtoichi13.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753031Ab1DHNU5 (ORCPT ); Fri, 8 Apr 2011 09:20:57 -0400 From: "J. R. Okajima" To: Al Viro , Christoph Hellwig , Nick Piggin cc: linux-kernel@vger.kernel.org Subject: Q. locking order of dcache_lru_lock Date: Fri, 08 Apr 2011 22:20:31 +0900 Message-ID: <9769.1302268831@jrobl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1237 Lines: 48 Hello Al Viro, Christoph Hellwig and Nick Piggin, I have a question about the locking order of dcache_lru_lock. The comment in fs/dcache.c says * Ordering: * dentry->d_inode->i_lock * dentry->d_lock * dcache_lru_lock ::: d_lock should be before dcache_lru_lock. Actually dentry_lru_(add|del|move_tail) functions (and their callers) do it expectedly. But __shrink_dcache_sb() looks different. __shrink_dcache_sb() { ::: relock: spin_lock(&dcache_lru_lock); while (!list_empty(&sb->s_dentry_lru)) { :: if (!spin_trylock(&dentry->d_lock)) { spin_unlock(&dcache_lru_lock); cpu_relax(); goto relock; } ::: } When spin_trylock(&dentry->d_lock) successfully acquired d_lock, does the violation of locking order happen (or a deadlock, in worse case)? By the way, the code is introduced by the commit 2304450 2011-01-07 fs: dcache scale lru by Nick Piggin. Is he allright? Does anyone know anything? We have not received from him for a long time. J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/