Messages in this thread | | | Date | Fri, 29 Oct 2010 06:14:34 +0100 | From | Al Viro <> | Subject | Re: [PATCH 4/8] fs: remove inode_lock from iput_final and prune_icache |
| |
On Fri, Oct 29, 2010 at 02:23:36PM +1100, Dave Chinner wrote: > From: Dave Chinner <dchinner@redhat.com> > > 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.
| |