Re: [PATCH] namei: implemented RENAME_NEWER flag for renameat2() conditional replace

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

 



On Tue, Jun 28, 2022 at 8:44 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Jun 27, 2022 at 04:11:07PM -0600, James Yonan wrote:
>
> >           && d_is_positive(new_dentry)
> >           && timespec64_compare(&d_backing_inode(old_dentry)->i_mtime,
> >                                 &d_backing_inode(new_dentry)->i_mtime) <= 0)
> >               goto exit5;
> >
> > It's pretty cool in a way that a new atomic file operation can even be
> > implemented in just 5 lines of code, and it's thanks to the existing
> > locking infrastructure around file rename/move that these operations
> > become almost trivial.  Unfortunately, every fs must approve a new
> > renameat2() flag, so it bloats the patch a bit.
>
> How is it atomic and what's to stabilize ->i_mtime in that test?
> Confused...

Good point.
RENAME_EXCHANGE_WITH_NEWER would have been better
in that regard.

And you'd have to check in vfs_rename() after lock_two_nondirectories()

Thanks,
Amir.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux