On Oct 21, 2014, at 5:17 PM, Al Viro wrote: >>> 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. 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. >> 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". Right. I have no problems with killing it since such a compat define is not needed in current kernel anyway. -- 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
