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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
