From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Altaparmakov Subject: A missing i_mutex in rename? (Linux kernel 2.6.latest) Date: Wed, 19 Apr 2006 11:50:00 +0100 (BST) Message-ID: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]:43411 "EHLO ppsw-0.csi.cam.ac.uk") by vger.kernel.org with ESMTP id S1750759AbWDSKuJ (ORCPT ); Wed, 19 Apr 2006 06:50:09 -0400 To: Al Viro Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi Al and other fs developers, Both sys_unlink()/sys_rmdir() and sys_link() all end up taking the i_mutex on all parent directories and source/destination inodes before calling into the file system inode operations. sys_rename() OTOH, does not take i_mutex on the old inode. It only takes i_mutex on the two parent directories and on the target inode if it exists. Why is this? To me it seems that either sys_rename() must take i_mutex on the old inode or sys_unlink()/sys_rmdir(), sys_link(), etc do not need to hold the i_mutex. What am I missing? ps. I verified my reading of the code by inserting a mutex_is_locked(old_dent->d_inode) in ->rename in ntfs and it returns negative no matter how I invoke the rename (i.e. it does not matter if source is a file or directory or whether a target exists, etc). pps. If indeed sys_rename() is correct in not needing the mutex and sys_unlink()/sys_rmdir(), sys_link(), etc are correct in needing the mutex, would it be safe if I just take old_dentry->d_inode->i_mutex on entry to ntfs_rename()? I would assume that there is no deadlock risk because the parent is already locked, correct? Thanks a lot in advance! Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/