Subject: RE: changes to nfs4_prot.x / protocol description

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 15 Oct 2001 20:16:49 -0700

> > > > > (2) Consider this scenario with three lockowners L1, L2, L3.
> > > > > Initially L1 has a file open with (open) stateid A, and L2 has
> > > > > the same file open with (open) stateid B.  The new LOCK operation
> > > > > is used to derive lock stateid C, for lockowner L3, from open
> > > > > stateid A.  The client then attempts to use the LOCK operation
> > > > > again to derive a new lock stateid, for lockowner L3, from open
> > > > > stateid B.  Does this:
> > > > >   (a) succeed, and instantiate new lock stateid D, which will
> > > > >       be independent from lock stateid C,
> > > > >   (b) succeed, but not instantiate a new lock stateid (the
> > > > >       server would return an updated version of stateid C), or
> > > > >   (c) fail with an error?
>
> At the risk of beating this issue to death, I found an example which
> I believe shows that (c) won't allow correct implementation of Posix
> clients, and that (a) is the only correct choice.

Beating this issue to death would be fine, if only it would stay dead.

> Consider this scenario:
>   1. Parent process P opens a file on file descriptor fd1, then forks
>      child process C (which inherits fd1).
>   2. Child C places a lock on fd1.
>   3. Child C closes fd1 (however, P still has it open).
>   4. Child C reopens the file on file descriptor fd2.
>   5. Child C places a lock on fd2.
>   6. With C still holding the lock, parent P closes fd1.

>
> Let's see how this scenario results in disaster if (c) is chosen above:
>   1. Lockowner P would transmit an OPEN, instantiating open stateid S1.
>   2. Lockowner C would transmit a LOCK, instantiating lock stateid L1
>      (derived from S1).
>   3. The close() here is a no-op as far as NFSv4 is concerned; rather
>      than sending a CLOSE to the server, the client will just decrement
>      an internal refcount (since P still has the file open).  (Of course,
>      the client would still need to send a LOCKU to release the lock
>      acquired in 2.)
>   4. Lockowner C would transmit an OPEN, instantiating open stateid S2.

What open-owner are you assuming C would use when doing the OPEN?  I
believe there are three ways of organizing things, all allowed by Spencer's
approach but each has different requirements regarding how the clients
account for open and closes.  

You can make an open-owner unique by combining process and a uniquifier.
In that case you don't have to worry about open upgrade and a close which
deletes the last reference results in a CLOSE over the wire.

You can have the open owner be the opening process.  In that case the client
does have to worry about open-upgrade and if you do two separrate opens,
then even if get rid of the last reference to the fd slot, you can't do an
don't necessarily do an over-the-wire CLOSE, although you might have to do
an OPEN_DOWNGRADE.

Or you can have open owner be the same for a set of related processes.  This
is similar to the previous case although the scope for which the server will
upgrade/ref count is larger and thus the client has to account for things
using that same larger scope.

So for these purposes, the issue is whether the open owner used by C
is the same as that used by P when it did it's OPEN.  If it is, then
the client must maintain enough state so that the close in step 6
does not result in an over-the-wire CLOSE.  If, on the other hand,
a different open-owner is used, then in step 5, the client can indeed
derive a new stateid from S2, at least as I understand (c).

(c) says, in my interpretation, that if you have open stateids for the same
file opened by the same open owner, you may not derive two independant
lock stateid sequences for the same lockowner from those two open stateid 
(and it follows that you can't derive the two lock stateid sequences 
from the same stareid).  You are allowed to derive two different
lock stateid sequences for the same lockowner given two open stateids
for the same file opened by *different* open owners.    

>   5. Assuming that (c) is chosen above, the client does not have the
>      option to instantiate a new lock stateid derived from S2 (this would
>      result in an error).  Rather, it must use the old lock stateid L1
>      in the LOCK request.
>   6. This close() destroys the last reference to the file table entry,
>      so it is not a no-op; rather it results in an nfsv4 CLOSE of stateid
>      S1.  This in turn destroys lock stateid L1 and the lock held by C.
>      So C has unexpectedly lost the lock on the file!

> On the other hand, if (a) is chosen, then in step 5 the client can derive
> a new lock stateid L2 from S2 and avoid the "disaster" in step 6.  I have
> convinced myself that the new state model will allow correct
> implementation of the Linux client, _provided_ that choice (a) is made in
> the original example.  So I'm now heavily pushing choice (a) as Spencer
> originally suggested.  Comments?

It's now time for Spencer to switch to (c) whereupon I will
be forced to adopt (b) to avoid any possibility of consensus :-)

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Tue, 16 Oct 2001 18:07:24 -0400 (EDT)

> for the same file opened by *different* open owners.

My interpretation is totally different!  In my interpretation, having
"open stateids for the same file opened by the same open owner" is
impossible.  If the same open owner opens the same file twice, this
results in an open upgrade, not a new open stateid.  At least, this
is how things have always been.  Was this changed with the adoption
of the new .x?

What I originally meant by (a) was precisely what you've said in the last
sentence above: that it is legal to derive seperate lock stateid
sequences, for the same lockowner, from different open stateids
corresponding to different open owners.  As long as this is legal, I think
that the Linux client is OK.  It sounds to me like you, Spencer, and I all
think that this ought to be legal, so we're actually in agreement on this
issue (much as one might think otherwise from reading all of these
messages!)  Is there anyone out there who doesn't think that this should
be legal?