On Oct 21, 2014, at 4:07 PM, Al Viro wrote: > On Tue, Oct 21, 2014 at 03:46:02AM +0000, Drokin, Oleg wrote: >> Hello! >> >> On Oct 20, 2014, at 9:13 PM, Al Viro wrote: >> >>> a) what protects ->d_name in ll_intent_file_open()? It copies >>> ->d_name.name and ->d_name.len into local variables and proceeds to >>> use those; what's to guarantee that dentry won't get hit with d_move() >>> halfway through that? None of the locks that would give an exclusion >>> against d_move() appear to be held… >> >> You are right. We hit something very similar not too long ago. > > Umm... While we are at it - what's the story with ll_setxattr() handling > of "trusted.lov"? What happens on the protocol level and why do we need > a file name for that, while for directories we don't seem to need it? trusted.lov is lustre striping information for files. Technically clients can only read this (as an xattr or via an ioctl) only. We have a separate RPC to actually set a desired striping, historically this was an ioctl on a file you had opened that had no prior striping. Later on when there appeared a need to be able to set file striping via xattr set (e.g. when restoring a file) it was decided to just reuse the existing setstriping code by creating a fake struct file and adding the dentry there. On the protocol level it's all transformed into a special OPEN request that also includes the desired striping hint (the passed in striping cannot be used verbatim since e.g. object numbers most definitely will change). Some older servers cannot do "open by fid" which is a fancy name for "open by inode number" and in that case the name is used to figure out what file is that we are working on (which is racy). In case of a directory, on the other hand, there's no actual object information, just a hint for how to allocate files in this dir. The setting on the protocol level is via a setattr RPC and it uses fid (inode number) at all times.-- 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
