This patch fixes a race between a task creating a new inode, and one writing that same new, dirty inode out to disk. We found this using a particular workload (fsstress) along with other ancillary processes running on the same machine. The symptom is one or more hung unkillable (uniterruptible sleep) tasks that try to operate on this new inode. The original comment block is wrong. Since the inode gets marked dirty after it's created, but before its I_LOCK bit is cleared, there _can_ be somebody else doing something with this inode -- e.g., a writeback task (in our case, __sync_single_inode()). Signed-off-by: Curt Wohlgemuth <curtw@xxxxxxxxxx> --- --- linux-2.6.29.1/fs/inode.c.orig 2009-04-02 13:55:27.000000000 -0700 +++ linux-2.6.29.1/fs/inode.c 2009-04-09 11:16:03.000000000 -0700 @@ -651,15 +651,14 @@ void unlock_new_inode(struct inode *inod } #endif /* - * This is special! We do not need the spinlock - * when clearing I_LOCK, because we're guaranteed - * that nobody else tries to do anything about the - * state of the inode when it is locked, as we - * just created it (so there can be no old holders - * that haven't tested I_LOCK). + * We need to hold the inode lock while clearing these bits, because + * there is a race between this code and the writeback path, since all + * of the new inode allocation routines will mark the inode as dirty. */ WARN_ON((inode->i_state & (I_LOCK|I_NEW)) != (I_LOCK|I_NEW)); + spin_lock(&inode_lock); inode->i_state &= ~(I_LOCK|I_NEW); + spin_unlock(&inode_lock); wake_up_inode(inode); } -- 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
