Normally all changes to ->i_state requires the ->i_lock spinlock held. The flag initially shows up in xfs_rename_alloc_whiteout, where I presume the inode is not visible to anyone else yet. It gets removed later in xfs_rename. I can't tell whether there is anyone else at that point who can mess with ->i_state. The context is that I'm writing a patchset which hides all ->i_state accesses behind helpers. Part of the functionality is to assert that the lock is held for changes of the sort. If this legitimately does not need the lock in your case I'll add some provisions to keep it that way. -- Mateusz Guzik <mjguzik gmail.com>
