On Thu, Jun 07, 2012 at 07:08:04PM -0700, Eric W. Biederman wrote: > > + dentry->d_fsdata = sysfs_get(sd); > > + ret = d_materialise_unique(dentry, inode); > > I have a small problem with d_materialise_unique. For renames of files > d_materialise_unique calls __d_instantiate_unique. __d_instantiate_unique > does not detect renames of files. Which at least misses the rename > of sysfs symlinks. Er... yes, but why do we care? It's not as if you had a hardwired reference to dentry from your objects, after all (can't, with multiple superblocks). So you get old stale dentry at the old location and a new one where we'd moved that sucker. They have the same inode and each holds a reference to the same sd; ->d_revalidate() at the old location must invalidate the old instance anyway, since you are not guaranteed that lookup at the new one will happen before repeated lookup at the old one. Directories *are* special in that respect, but symlinks are trivial... VFS doesn't care if you have extra dentries for those and neither does sysfs, AFAICS. It's not that we couldn't teach d_materialise_unique() about those (e.g. introduce a new dentry flag and treat dentries with it as directories for d_materialise_unique() purposes); I would like to understand the reasons for doing that, though. -- 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
