Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751646AbWHNIpS (ORCPT ); Mon, 14 Aug 2006 04:45:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751959AbWHNIpR (ORCPT ); Mon, 14 Aug 2006 04:45:17 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]:6104 "EHLO ppsw-7.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S1751646AbWHNIpP (ORCPT ); Mon, 14 Aug 2006 04:45:15 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Subject: Re: CIFS & Lockdep warnings From: Anton Altaparmakov To: Andrew Morton Cc: Srihari Vijayaraghavan , lkml , sfrench@samba.org, Anton Altaparmakov In-Reply-To: <20060813185102.e01898b9.akpm@osdl.org> References: <20060814010503.2932.qmail@web52605.mail.yahoo.com> <20060813185102.e01898b9.akpm@osdl.org> Content-Type: text/plain Organization: Computing Service, University of Cambridge, UK Date: Mon, 14 Aug 2006 09:44:59 +0100 Message-Id: <1155545099.6673.27.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3265 Lines: 83 On Sun, 2006-08-13 at 18:51 -0700, Andrew Morton wrote: > On Mon, 14 Aug 2006 11:05:03 +1000 (EST) > Srihari Vijayaraghavan wrote: > > > This is observed on 2.6.18-rc4 on SUSE 10.1 x86 on > > P-IV. The volume is question was mounted from a > > Windows 2003 server. > > > > ======================================================= > > [ INFO: possible circular locking dependency detected > > ] > > ------------------------------------------------------- > > cp/11790 is trying to acquire lock: > > (iprune_mutex){--..}, at: [] > > mutex_lock+0x19/0x20 > > > > but task is already holding lock: > > (&inode->i_mutex){--..}, at: [] > > mutex_lock+0x19/0x20 > > > > which lock already depends on the new lock. > > > > > > the existing dependency chain (in reverse order) is: > > > > -> #1 (&inode->i_mutex){--..}: > > [] lock_acquire+0x56/0x73 > > [] __mutex_lock_slowpath+0xa6/0x1ec > > [] mutex_lock+0x19/0x20 > > [] ntfs_put_inode+0x3e/0x79 [ntfs] > > [] iput+0x33/0x70 > > [] inotify_unmount_inodes+0x12e/0x15f > > [] invalidate_inodes+0x38/0xd1 > > [] generic_shutdown_super+0x5a/0x108 > > [] kill_block_super+0x20/0x36 > > [] deactivate_super+0x61/0x78 > > [] mntput_no_expire+0x44/0x78 > > [] path_release_on_umount+0x16/0x1d > > [] sys_umount+0x1d2/0x208 > > [] sys_oldumount+0xd/0xf > > [] syscall_call+0x7/0xb > > NTFS takes i_mutex inside iprune_mutex. NTFS _should_ be deadlocking > because of this (iprune_mutex nests inside i_mutex on the write() path) but > somehow it gets away with it. Directories are not subject to write(2) or at least not last time I checked. And ntfs_put_inode() only operates on directories... To quote current 2.6 kernel/fs/ntfs/inode.c: void ntfs_put_inode(struct inode *vi) { if (S_ISDIR(vi->i_mode) && atomic_read(&vi->i_count) == 2) { ntfs_inode *ni = NTFS_I(vi); if (NInoIndexAllocPresent(ni)) { struct inode *bvi = NULL; mutex_lock(&vi->i_mutex); if (atomic_read(&vi->i_count) == 2) { bvi = ni->itype.index.bmp_ino; if (bvi) ni->itype.index.bmp_ino = NULL; } mutex_unlock(&vi->i_mutex); if (bvi) iput(bvi); } } } Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/ - 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/