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 Fri, Sep 12, 2025 at 10:23:39AM +0200, Miklos Szeredi wrote:
> On Fri, 12 Sept 2025 at 07:49, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > While we are at it, Miklos mentioned some plans for changing ->atomic_open()
> > calling conventions.  Might be a good time to revisit that...  Miklos,
> > could you give a braindump on those plans?
> 
> [Cc: Bernd]
> 
> What we want is ->atomic_open() being able to do an atomic revalidate
> + open (cached positive) case.  This is the only case currently that
> can't be done with a single ATOMIC_OPEN request but needs two
> roundtrips to the server.
> 
> The ->atomic_open() interface shouldn't need any changes, since it's
> already allowed to use a different dentry from the supplied one.
> 
> 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()...

	Or am I misreading you?