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 Thanks, Miklos
