On Sat, 13 Sep 2025, Al Viro wrote: > 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()... Once we get per-dentry locking for dirops this will cease to be a problem. The dentry would be locked exclusively whether we create or not and the lock would prevent the d_splice_alias() rename. NeilBrown > > Or am I misreading you? >
