On 6/28/22 23:15, Amir Goldstein wrote:
because the application layer has already done the heavy lifting on the
networking side so that the filesystem layer can be local, fast, and
atomic. So yes, I haven't tested this yet on networked filesystems.
But I'm thinking that because all functionality is implemented at the
VFS layer, it should be portable to any fs that also supports
RENAME_NOREPLACE, with the caveat that it depends on the ability of the
VFS to get a current and accurate mtime attribute inside the critical
section between lock_rename() and unlock_rename().
The implementation is generic. You just implement the logic in the vfs and
enable it for a few tested filesystems and whoever wants to join the party
is welcome to test their own filesystems and opt-in to the new flag whether
they like. Nothing wrong with that.
w.r.t stability of i_mtime, if I am not mistaken i_mtime itself is
stable with inode
lock held (i.e. after lock_two_nondirectories()), however, as Dave pointed out,
the file's data can be modified in page cache, so as long as the file is open
for write or mmaped writable, the check of mtime is not atomic.
Neil's suggestion to deny the operation on open files makes sense.
You can use a variant of deny_write_access() that takes inode
which implies the error ETXTBSY for an attempt to exchange newer
with a file that is open for write.
So I will incorporate these suggestions into an upcoming v2 patch.
Thanks,
James
