On Tue, Oct 21, 2014 at 01:34:57PM +0000, Drokin, Oleg wrote: > I think it makes sense indeed. > The "get rid of duplicate mountpoint checks" patch has a hunk at ll_link > that looks like it belongs to "kill ll_link_generic()" patch, > otherwise the intermediate result is somewhat strange. Thanks; fixed and force-pushed. > > Another question: what's wrong with d_splice_alias() or d_materialise_unique()? > > I.e. why do we need ll_splice_alias()? I have patches in local queue > > We used to need it to also find and reuse invalid aliases, so that the dentry > cache does not get out of control with constant dentry invalidations we have. > > I checked the code and now that d_splice_alias is calling __d_find_any_alias > that seems to just pick the first alias off the list, we should be fine ITYM "the one and only". That's pretty much what d_splice_alias() is about - we do not allow more than one dentry (be it hashed or not) for a directory inode, so d_add() variant that can run into directory inode already with a dentry _must_ use that existing dentry instead of what it's been given. That's why we need it to be able to move a preexisting dentry in place of the one it's been given and return a new reference to that preexisting dentry. For non-directories and for directories that have no aliases it's just d_add() and return NULL. > with just using generic d_splice_alias. BTW, mind if we kill ll_umode_t? This kind of compat wrappers is the wrong way - it should be "supply an equivalent of more recent kernel stuff when builds on older kernels". -- 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
