On Thu, Jun 07, 2012 at 04:12:45PM -0700, Eric W. Biederman wrote: > We take the approprate dentry locks in the approparite order so d_move > and the dcache should not care in the slightest about the inode > mutecies. > > If we need the inode mutecies to make the dcache bits safe then > something really is insane. There may be subtle insanities in the > vfs that require the inode muticies of the parents in d_move but I am > certainly not seeing them. At least as I read it the code in __d_move > only touches and modifies dentry fields. Yes. Now, go take a look at e.g. the locking order on ->d_lock. No, I'm not saying that I like it. Not at all. But we do rely on the non-local protections for tree topology, just to make sure that the damn thing has the locking order consistent - not changing between the moments you take locks you've ordered, for starters. I realize that "serialize all operations on a single per-machine mutex" is a solution. It's just not something feasible when we are talking about all directory tree modifications on a general-purpose filesystem. So no, sysfs approach to that kind of problems is not usable here. I doubt that we have something sysfs-related in the deadlocks davej is seeing, but I seriously suspect that I can cook one based on sysfs_rename() setting the things up for silent topology changes on ->lookup(). I would suggest using d_materialise_unique() there - that one *does* take care to take locks needed. BTW, looking at the code in sysfs_lookup()... why bother with d_set_d_op() instead of just sb->s_d_op = &sysfs_dentry_ops; once during sysfs_fill_super()? In the worst case you need to do that after you've allocated the root dentry, depending on whether you are willing or not to make ->d_revalidate() return 1 whenever it's called on the root dentry... -- 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
