On Wed, Oct 22, 2014 at 01:48:48AM +0000, Drokin, Oleg wrote: > Ah! I see now. > We do the "pick alias from a list" for everything, not just for the directories. > So that difference is still missing and as such there is a fear if we > convert to d_splice_alias in its current form, dcache would explode > from all the gazillions of invalid and unhashed dentries we produce during > operations. Interesting... Where do those gazillions come from? AFAICS, your ->d_revalidate() does that only when you get LOOKUP_OPEN | LOOKUP_CREATE in flags, i.e. on the final component of pathname at open() with O_CREAT. Hmm... So basically you are trying to force them into ->atomic_open() codepath? Fine, but... why not simply have ->open() pick what hadn't gone through ->atomic_open()? Check what nfs4_file_open() is doing; if you find out that the damn thing *was* stale (i.e. that you really need a different inode, etc.), it's not a problem - d_drop() and return -EOPENSTALE; VFS will repeat lookups. Note that do_dentry_open() doesn't strip O_CREAT from file->f_flags until after return from ->open(). So you can see O_CREAT in ->open() just fine - this case is easy to distinguish there. Incidentally, why the hell do you have separate ll_revalidate_nd() and ll_revalidate_dentry()? I realize that it'll be inlined by compiler (the only call of the latter is tail-call with identical arguments from the former), but... Another nasty question: is d_need_statahead() safe in RCU pathwalk mode? When are ll_dentry_data and ll_inode_info freed? Ditto for ->lli_sai. Sure, actual freeing of struct inode and struct dentry is RCU-delayed, but from the quick glance it seems that freeing those guys isn't... -- 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
