Re: [RFC] atomic create+open

[Trond Myklebust <trond.myklebust@fys.uio.no>]

fr den 07.10.2005 Klokka 17:18 (+0200) skreiv Miklos Szeredi:

> > > You can replace the inode in ->create_open() if you want to.  Or let
> > > the VFS redo the lookup (as if d_revalidate() returned 0).
> > 
> > ...but I cannot do that once I get to dentry_open(). You are ignoring
> > the case of generic file open without creation.
> 
> You can't do open by inode number (or file handle, whatever)?  Only by
> name?  In that case yes, I see your problem.

As I believe I said earlier, open by inode number/filehandle/... don't
exist in the NFSv4 protocol due to the potential for races.

> > > NFS does OPEN (O_CREAT), file is opened, dentry replaced (this is not
> > > ellaborated in the pseudocode).
> > 
> > Which again only deals with the case of open(O_CREAT). My point is that
> > the race exists for the case of generic open().
> 
> And so does for setattr() etc.  You can safely return -ENOENT in these
> cases.  O_CREAT is problematic only because it cannot return -ENOENT
> if the file was removed between ->lookup and ->open.

No. There is no race for setattr() etc since they only do one lookup
(and they don't set up any state on the server).

open() is the only case where we currently have to look things up twice
(and I remind you that the second "lookup" is in fact the OPEN
operation).

Trond