On Sun, Sep 14, 2025 at 09:01:40PM +0200, Miklos Szeredi wrote: > On Sat, 13 Sept 2025 at 07:07, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > How would that combined revalidate+open work for fuse, anyway? The former > > is basically a lookup - you send nodeid of parent + name, get nodeid + > > attributes of child. The latter goes strictly by nodeid of child and > > gets a 64bit number that apparently tells one opened file from another > > (not to be confused with fhandle). Combined request of some sort? > > There are already two combined ones: FUSE_CREATE and FUSE_TMPFILE both > get nodeid of parent + name and return attributes of child plus opened > file. FUSE_CREATE gets invoked in the uncached or cached negative > case from ->atomic_open() with inode lock for held exclusive. > > That leaves 2 cases: > > - uncached plain open: FUSE_OPEN_ATOMIC with same semantics as > FUSE_CREATE, inode lock held shared > > - cached positive (plain or O_CREAT): FUSE_OPEN_REVAL getting nodeid > of parent + name + nodeid of child and return opened file or -ESTALE, > no locking required What happens if the latter overlaps with rename? Or, for a cached directory inode, with lookup elsewhere picking the same inode as our cached (and possibly invalid, but we don't know that) dentry?
