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

[Miklos Szeredi <miklos@szeredi.hu>]

On Fri, 12 Sept 2025 at 20:29, Al Viro <viro@zeniv.linux.org.uk> 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