On 03/28/2011 03:54 PM, Matthew Wilcox wrote: > On Mon, Mar 28, 2011 at 02:56:00PM +1300, Ryan Mallon wrote: >> Commit 250df6ed274d767da844a5d9f05720b804240197 "fs: protect >> inode->i_state with inode->i_lock" changes igrab to acquire inode->i_lock, >> however some callees, notably nfs_inode_add_request, already hold the lock >> when calling igrab. > > I think a better solution to your problem is to notice that this is > called in the context of doing a write to an inode. That means we > must already have a reference count on this inode, so it can't possibly > be in I_FREEING or I_WILL_FREE. That means we can just call __iget() > instead ... except that __iget isn't exported to modules. Ah, okay. Thanks for the hint. A few other locations that I can see that call igrab with inode->i_lock held are: fs/ceph/snap.c::ceph_queue_cap_snap fs/ceph/addr.c::ceph_set_page_dirty fs/nfs/nfs4state.c::nfs4_get_open_state There may be some more cases where the locking is less obvious. I don't know enough about the filesystem code to say whether each of those can skip the (I_FREEING | I_WILL_FREE) check, or whether the correct approach is to modify the filesystems themselves so that they do not hold i_lock when calling igrab (i.e. rework to use a different outer lock)? If the correct approach is to use __iget or __igrab then I can prepare a patch for this. In the case of __iget, should it just be marked EXPORT_SYMBOL and added to include/linux/fs.h? ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon 5 Amuri Park, 404 Barbadoes St ryan@xxxxxxxxxxxxxxxx PO Box 13 889, Christchurch 8013 http://www.bluewatersys.com New Zealand Phone: +64 3 3779127 Freecall: Australia 1800 148 751 Fax: +64 3 3779135 USA 1800 261 2934 -- 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
