On Fri, Sep 12, 2025 at 10:23:39AM +0200, Miklos Szeredi wrote: > On Fri, 12 Sept 2025 at 07:49, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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?
