Subject: [nfsv4] Another question, this one for RFC 7530

From: "Frank Filz" <[email-masked]>
Date: Wed, 30 Sep 2015 12:02:10 -0700

It's not clear whether a client is allowed to send a LOCK request with
new_lock_owner true when the client has previously done so for the same lock
owner and file (and thus the server has an active stateid for that
owner/file pair). If it is allowed, should the server re-use the same
stateid, or discard the old stateid and issue a new one?

Thanks

Frank

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Rick Macklem <[email-masked]>
Date: Wed, 30 Sep 2015 18:50:33 -0400 (EDT)

> stateid, or discard the old stateid and issue a new one?
I don't believe that the RFCs state this explicitly, but the combination of
"new" and no obvious answer to your above question (how to handle it, if allowed)
made me decide to consider it an error.

The FreeBSD server will return NFS4ERR_INVAL for this and I'll be curious to see
what others think?

I have not heard of this causing a problem for extant clients.

Fyi, the FreeBSD server does allow the same lock stateid to be used for multiple
file handles, but logs that it encountered this and to the best of my knowledge,
this has never been logged.

As such, I believe extant client use the open_to_lock_owner case to create a lock
stateid for each (FH, lock_owner) tuple and only if it doesn't already have a lock
stateid for the tuple.

Hopefully others can clarify this for you more definitively, rick

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: "Frank Filz" <[email-masked]>
Date: Wed, 30 Sep 2015 16:29:05 -0700

> > new_lock_owner true when the client has previously done so for the
> > same lock owner and file (and thus the server has an active stateid
> > for that owner/file pair). If it is allowed, should the server re-use
> > the same stateid, or discard the old stateid and issue a new one?
> >
> "new" and no obvious answer to your above question (how to handle it, if
> allowed) made me decide to consider it an error.
> 
> The FreeBSD server will return NFS4ERR_INVAL for this and I'll be curious to
> see what others think?
> 
> Fyi, the FreeBSD server does allow the same lock stateid to be used for
> multiple file handles, but logs that it encountered this and to the best of my
> knowledge, this has never been logged.
> 
> As such, I believe extant client use the open_to_lock_owner case to create a
> lock stateid for each (FH, lock_owner) tuple and only if it doesn't already
> have a lock stateid for the tuple.
> 

At least some version(s) of Linux client (RHEL 6.4) has demonstrated an issue, running cthon04 lock test8. Apparently the client loses track of the stateid during the repeated lock/unlock cycles this test does. The Ganesha server currently ends up returning an NFS4ERR_RESOURCE, which certainly needs to change whatever the decision in this case is.

Frank

---