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 <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
