Re: [RFC] atomic create+open

[Miklos Szeredi <miklos@szeredi.hu>]

> fr den 07.10.2005 Klokka 15:59 (+0200) skreiv Miklos Szeredi:
> > So, you are saying OPEN has to do the lookup too.  That's OK, but that
> > _does not_ mean that you have to do the OPEN operation from the
> > ->lookup() or ->d_revalidate() methods.  In fact you cannot do the
> > later without getting into trouble over mounts.
> 
> You cannot do anything else without getting into trouble over dentry
> races. Given that choice, I prefer to take my chances with the mounts as
> those are rare.
> 
> We can add locking in order to exclude the mount races, or we can just
> ignore them. AFAICS there are 2 cases:
> 
>   1) umount races
> 	refcounting of any in-use dentry is supposed to prevent trouble here.

Refcounting solves nothing.  The problem is that you try to do the
mount handling partly in the filesystem, and partly outside of it.

I hate the idea of this, but if there's no alternative...

>   2) mount races. Either
> 	Just ignore if the filesystem has already opened the file.

Yes, ignoring is perfectly fine.  Unlike the umount case, mounting
cannot cause problems.

> > 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.

> > 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.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/