Re: [RFC] atomic create+open

[Miklos Szeredi <miklos@szeredi.hu>]

> > > 
> > > Which may return yet another result for the dentry and another race.
> > > There is no guarantee that you will ever make progress if someone is
> > > doing something like.
> > > 
> > > while true
> > > do
> > >   echo "1" > foo
> > >   echo "2" > foo
> > > done
> > > 
> > > on the server.
> > 
> > Not good example. This won't change the file, only the contents.
> > Something with rename would be better.
> 
> Sorry, yes. This tweak should demonstrate what I meant
> 
> while true
> do
>   echo "1" > foo
>   echo "2" > bar
>   mv bar foo
> done
> 
> > We are still pitting two different races against each other.  I can't
> > see such a big difference in ugliness...
> 
> No we're not. I telling you that your open_create is not a solution for
> the problems we have with open in NFSv4.

OK, I think I see the problem better now.

> If it doesn't do atomic lookup+open, then I have an unfixable race. Any
> "solution" that requires NFS to assume that the dcache will remain
> consistent with the server namespace across more than one RPC operation
> is prone to races.
> 
> OTOH mount/umount races are fixable since they involve only the local
> namespace. Just add locking.

You _could_ take the namespace semaphore across lookup_hash() and
follow_mount(), but I'm not sure everybody would like that.

Are you planning to post a patch?  Atomic open+create is something
that FUSE wants as well, so it would be nice to get a proper solution
into the kernel.

I'll think a bit more about solving the mount thing properly.

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/