On Fri, 12 Sept 2025 at 20:29, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > Based on (flags & LOOKUP_OPEN) ->revalidate() needs to tell the caller > > that it's expecting the subsequent ->atomic_open() call to do the > > actual revalidation. The proposed interface for that was to add a > > D_REVALIDATE_ATOMIC = 2 constant to use as a return value in this > > case. > > Umm... Unless I'm misunderstanding you, that *would* change the > calling conventions - dentry could bloody well be positive, couldn't it? > And that changes quite a bit - without O_CREAT in flags you could get > parent locked only shared and pass a positive hashed dentry attached > to a directory inode to ->atomic_open(). The thing is, in that case it > can be moved by d_splice_alias()... You are talking about the disconnected directory case? That can't happen in this call path, since it's following a normal component from a parent directory, which by definition isn't disconnected. Just realized, that open_last_lookups() will bypass lookup_open() on cached positive anyway, so really no point in handing that inside lookup_open(). Should this be done via a new i_op->reval_open() called without inode lock, with a positive dentry and gets a name just like d_revalidate? Thanks, Miklos
