On Fri, Nov 11, 2016 at 1:17 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Nov 11, 2016 at 01:11:16AM +0200, Amir Goldstein wrote: > >> That is explained in commit message of the first 2 patches, but >> foremost I would like to say that the name "delete locked" is just the >> best of all the bad choices for names I came up with, so I am expecting >> better name suggestions. >> >> The concept is to pin the entry so that it cannot be moved, so can have >> certain guaranties about the stability of the directories topology. >> >> > More specifically, what makes you think that may_delete() is called before >> > any change of parent? >> >> Because it is checked at the beginning of vfs_rename() >> and in order to change a parent, an entry needs to be renamed. no? >> What am I missing? > > Analysis of the rest of call chains where we have __d_move() called? Not > to mention anything else, workdir itself might be moved around by > d_splice_alias() for a sufficiently unpleasant filesystem... I am certainly looking for this feedback, because there is no other means for me to sanity test if relaxing lock_rename() is safe. When I write "any change of parent" I mean a change between 2 different connected parents. Both work dir and upper dir are connected and with reference held after mount. Are the d_splice_alias() and __d_unalias() cases a real concern for moving work dir around after the overlay mount?? Plus, if a file system is sufficiently unpleasant, perhaps there is a way to categorize it as such by ovl_dentry_weird(), if it hasn't been categorized as such already. -- 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
