On Fri, Oct 29, 2010 at 02:23:36PM +1100, Dave Chinner wrote: > From: Dave Chinner <dchinner@xxxxxxxxxx> > > Now that inode state changes are protected by the inode->i_lock and > the inode LRU manipulations by the inode_lru_lock, we can remove the > inode_lock from prune_icache and the initial part of iput_final(). > > instead of using the inode_lock to protect the inode during > iput_final, use the inode->i_lock instead. This protects the inode > against new references being taken while we change the inode state > to I_FREEING, as well as preventing prune_icache from grabbing the > inode while we are manipulating it. Hence we no longer need the > inode_lock in iput_final prior to setting I_FREEING on the inode. > > For prune_icache, we no longer need the inode_lock to protect the > LRU list, and the inodes themselves are protected against freeing > races by the inode->i_lock. Hence we can lift the inode_lock from > prune_icache as well. Careful. At that point we still rely on inode_lock to protect inode_unhashed(). Note that ->drop_inode() uses it a lot and this step moves it from inode_lock to ->i_lock. What you need to do is pretty simple - make remove_inode_hash() take both inode_lock (later - inode_hash_lock) and ->i_lock. That's enough for inode_unhashed() protection, but I'd also hold ->i_lock on insertions into hash. It's trivial (we hold ->i_lock just next to that insertion) and would make for more consistent rules. -- 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
