Re: [nfsv4] OPEN_DOWNGRADE and posix byte range locking issue

I think that it might be better to disallow automatically freeing locks
since the server does not always know which lock_owner (!= open_owner)
is affected by the close() system call that triggered the OPEN_DOWNGRADE
on the client.

In the case of CLOSE, the choice of lock_owners is unambiguous, since it
is very clear that all lock stateids that were associated to the open
stateid in question must be released.

Cheers
  Trond

On Thu, 2010-07-08 at 15:50 -0400, Noveck_David@emc.com wrote:
> Makes sense to me.
> 
> 18.10.4 of RFC 5661 says:
> 
>    LOCK operations are subject to permission checks and to checks
>    against the access type of the associated file.  However, the
>    specific right and modes required for various types of locks reflect
>    the semantics of the server-exported file system, and are not
>    specified by the protocol. 
> 
> Given that LOCK may exclude locks for write on files not open for write,
> it makes sense that downgrade whereby a file can become
> not-open-for-write when it previously was, has to reject a request which
> would violate the invariant.
> 
> Sounds like we need a paragraph in DOWNGRADE explaining the issue as
> well as adding the error to the list.
> 
> I think there is a another potential issue here.  CLOSE is allowed to
> (but not required to) release byte-range locks.  I think windows does
> that.
> 
> The issue I'm wondering about is whether a server is allowed to release
> locks for write as a valid response to DOWNGRADE.  This is separate from
> the issue of LOCKS_HELD, which I agree it needs to be able to do.  I
> think we also agree that a server may allow the write locks to stay.
> The interesting question is whether there is a third choice: silently
> getting rid of the locks that have become inappropriate to the new open
> mode.  
> 
> When we fix this, we should be clear on what is and isn't allowed.
> 
> 
> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
> Of Trond Myklebust
> Sent: Wednesday, July 07, 2010 7:30 PM
> To: nfsv4@ietf.org
> Subject: [nfsv4] OPEN_DOWNGRADE and posix byte range locking issue
> 
> Neither RFC3530, nor RFC5661 appear to list NFS4ERR_LOCKS_HELD as a
> valid response when the client calls OPEN_DOWNGRADE.
> 
> The question is: what should the server then do if the NFS client holds
> a WRITE_LT lock, but then asks for an OPEN_DOWNGRADE to
> OPEN4_SHARE_ACCESS_READ. I understand that this is sanctioned in Windows
> server environments, but it should definitely be forbidden in a POSIX
> environment, and NFS4ERR_LOCKS_HELD would appear to fit the bill...
> 
>  Trond
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4