On Tue 02-11-10 19:45:36, Christoph Hellwig wrote: > iprune_sem is continously giving us lockdep warnings because we do take it in > read mode in the reclaim path, but we're also doing non-NOFS allocations under > it taken in write mode. > > Taking a bit deeper look at it I think it's fixable quite trivially: > > - for invalidate_inodes we do not need iprune_sem at all. We have an active > reference on the superblock, so the filesystem is not going away until it > has finished. > - for evict_inodes we do need it, to make sure prune_icache has done it's > work before we tear down the superblock. But there is no reason to > hold it over the actual reclaim operation - it's enough to cycle through > it after the actual reclaim to make sure we wait for any pending > prune_icache to complete. The patch is OK but it's kind of subtle that evict_inodes() can now skip some inode in the LRU list because prune_icache() is just processing it and so it has elevated i_count. Everything will work out fine because MS_ACTIVE is cleared and thus iput() will destroy the inode and prune_icache() will then just continue with the next inode in the inode_lru list. But as I said above it's subtle... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
