Re: [RFC][PATH 4/4] ovl: relax lock_rename when moving files between work and upper dir

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux