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

[Anton Altaparmakov]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/