A missing i_mutex in rename? (Linux kernel 2.6.latest)

Anton Altaparmakov
2006-04-19T10:50:11Z

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!