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
