On Tue, Apr 29, 2014 at 04:04:11PM -0700, Linus Torvalds wrote: > But at a minimum, we have "d_op->d_prune()" that would now be possibly > be called for the old dentry *after* a new dentry has been allocated. > Not to mention the inode not having been dropped. So it looks like a > disaster where the filesystem now ends up having concurrent "live" > dentries for the same entry. Even if one of them is on its way out, > it's still visible to the filesystem. That makes me very > uncomfortable. > > I'm starting to think that Miklos' original patch (perhaps with the > spinlock split to at least be one per superblock) is the most > straightforward approach after all. It's annoying having to add locks > here, but the whole pruning path should not be a hotpath, so maybe > it's not actually a big deal. FWIW, my solution is more or less working; I'll give more local beating and post it... -- 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
