On 05/14/2013 09:22 AM, Dave Chinner wrote: > I've found the problem. dentry_kill() returns the current dentry if > it cannot lock the dentry->d_inode or the dentry->d_parent, and when > that happens try_prune_one_dentry() silently fails to prune the > dentry. But, at this point, we've already removed the dentry from > both the LRU and the shrink list, and so it gets dropped on the > floor. > Great. I had already an idea that it had something to do with a dentry being removed from the LRU and not being put back, but I was looking at the wrong circumstance. oz, oz oi oi oi! > patch 4 needs some work: > > - fix the above leak shrink list leak > - fix the scope of the sb locking inside shrink_dcache_sb() > - remove the readditional of dentry_lru_prune(). I readded this just because there are more work that needs to be done upon prune that is always the same. This is specially true in later patches, IIRC. I don't think dentry_lru_prune() has anything to do directly with the problem we are seeing now, and this is just a question of duplicated code vs not. But I am ultimately fine either way. -- 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
