On Fri, 20 May 2022 at 06:07, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Thu, May 19, 2022 at 04:43:58PM +0200, Miklos Szeredi wrote: > > Hi Al, > > > > Do you see anything bad with allowing ->atomic_open() to take a positive dentry > > and possibly invalidate it after it does the atomic LOOKUP/CREATE+OPEN? > > > > It looks wrong not to allow optimizing away the roundtrip associated with > > revalidation when we do allow optimizing away the roundtrip for the initial > > lookup in the same situation. > > Details, please - what will your ->atomic_open() do in that case? It will do an open-by-name or create-and-open depending on the flags. It will return whether the file was created or not. If created, then the old positive is obviously stale, so it will be invalidated and a new one allocated. If not created, then check whether it's the same inode (same as in ->d_revalidate()) and if not, invalidate & allocate new dentry. Thanks, Miklos
