[LTP] [PATCH] NFS: add atomic_open for NFSv3 to handle O_TRUNC correctly.
NeilBrown
neilb@suse.de
Tue Jun 11 04:29:42 CEST 2024
On Fri, 07 Jun 2024, James Clark wrote:
>
> Hi Neil,
>
> Now that your fix is in linux-next the statvfs01 test is passing again.
> However inotify02 is still failing.
>
> This is because the test expects the IN_CREATE and IN_OPEN events to
> come in that order after calling creat(), but now they are reversed. To
> me it seems like it could be a test issue and the test should handle
> them in either order? Or maybe there should be a single inotify event
> with both flags set for the atomic open?
Interesting.... I don't see how any filesystem that uses ->atomic_open
would get these in the "right" order - and I do think IN_CREATE should
come before IN_OPEN.
Does NFSv4 pass this test?
IN_OPEN is generated (by fsnotify_open()) when finish_open() is called,
which must be (and is) called by all atomic_open functions.
IN_CREATE is generated (by fsnotify_create()) when open_last_lookups()
detects that FMODE_CREATE was set and that happens *after* lookup_open()
is called, which calls atomic_open().
For filesystems that don't use atomic_open, the IN_OPEN is generated by
the call to do_open() which happens *after* open_last_lookups(), not
inside it.
So the ltp test must already fail for NFSv4, 9p ceph fuse gfs2 ntfs3
overlayfs smb.
Can you confirm is that is, or is not, the case?
Thanks,
NeilBrown
More information about the ltp
mailing list