On Sun, 14 Sept 2025 at 21:50, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Sep 14, 2025 at 09:01:40PM +0200, Miklos Szeredi wrote: > > - 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? In the overlapping rename case either result is okay: if the open succeeded, that means open won the race against rename. If on the other hand open_reval lost and didn't find the expected child, then dentry is going to get invalidated and the whole thing retried ending up with open_atomic or open_creat with no further races possible. With the stale dentry getting moved by d_splice_alias() it's a slightly different story. The dentry starts out stale, but by being moved to its proper place it becomes uptodate again. So before invalidating it, it would make sense to check whether the parent and the name still matches the one we are looking up. But that race happens with plain ->d_revalidate() as well AFAICS, so that wouldn't be a new thing. Thanks, Miklos
