Re: ->atomic_open() fun (was Re: [RFC] a possible way of reducing the PITA of ->d_name audits)

[Al Viro <viro@zeniv.linux.org.uk>]

On Sun, Sep 14, 2025 at 09:01:40PM +0200, Miklos Szeredi wrote:
> On Sat, 13 Sept 2025 at 07:07, Al Viro <viro@zeniv.linux.org.uk> 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?