On Friday November 30, dgc@xxxxxxx wrote: > On Fri, Nov 30, 2007 at 09:07:06AM +1100, Neil Brown wrote: > > > > Hi David, > > > > On Friday November 30, dgc@xxxxxxx wrote: > > > > > > > > > I came across this because I've been making changes to XFS to avoid the > > > inode hash, and I've found that I need to remove the inode from the > > > dirty list when setting I_WILL_FREE to avoid this race. I can't see > > > how this race is avoided when inodes are hashed, so I'm wondering > > > if we've just been lucky or there's something that I'm missing that > > > means the above does not occur. > > > > Looking at inode.c in 2.6.23-mm1, in generic_forget_inode, I see code: > > > > if (!hlist_unhashed(&inode->i_hash)) { > > if (!(inode->i_state & (I_DIRTY|I_SYNC))) > > list_move(&inode->i_list, &inode_unused); > > > > so it looks to me like: > > If the inode is hashed and dirty, then move it (off the s_dirty > > list) to inode_unused. > > That check is for if the inode is _not_ dirty or being sync, right? > Or have I just not had enough coffee this morning? :-) And I cannot even blame the lack of coffee as I don't drink it. My second guess is that we have been lucky.... which is hard to believe. I wonder if iput (and even iget) should BUG on I_WILL_FREE as well... Perplexed. NeilBrown - 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