Asking for details about OPEN_DOWNGRADE

[J. Bruce Fields]

On Fri, Jun 13, 2008 at 10:33:15AM -0700, Mike Mackovitch wrote:
> On Fri, Jun 13, 2008 at 10:03:29AM -0700, eric kustarz wrote:
> >
> > On Jun 13, 2008, at 9:49 AM, Mike Mackovitch wrote:
> >
> >> On Fri, Jun 13, 2008 at 08:01:03AM -0400, Trond Myklebust wrote:
> >>> On Fri, 2008-06-13 at 11:23 +0200, philippe.deniel at cea.fr wrote:
> >>>>     The
> >>>>    share_access and share_deny bits specified must be exactly equal to
> >>>>    the union of the share_access and share_deny bits specified for some
> >>>>    subset of the OPENs in effect for current openowner on the current
> >>>>    file.
> >>>
> >>> It basically means that in order to be allowed to downgrade to
> >>> OPEN4_SHARE_ACCESS_READ|OPEN4_SHARE_DENY_NONE, then at least one of  
> >>> the
> >>> OPENs that made up the previous stateid must have been of that type.
> >>
> >> What's strange is that it appears that only Linux seems to think
> >> this is the case.  I can't figure out (1) why they think it must
> >> work this restrictively (my best guess is that the phrase "OPENs in
> >> effect" is being misinterpreted as "OPENs sent to the server"), and
> >> (2) why they haven't bothered/managed to convince the rest of the
> >> NFSv4 community of this (and get the spec updated).
> >>
> >>> IOW: you cannot just do
> >>>
> >>>        OPEN(OPEN4_SHARE_ACCESS_BOTH|OPEN4_SHARE_DENY_NONE)
> >>>        OPEN_DOWNGRADE(OPEN4_SHARE_ACCESS_READ|OPEN4_SHARE_DENY_NONE) = NFS4ERR_INVAL
> >>
> >> This works fine on Solaris server - and the Solaris client
> >> even behaves exactly this way.
> >
> > Yeah, we've got some bugs to fix in this area:
> > NFSv4 client can send a bogus OPEN_DOWNGRADE
> > http://bugs.opensolaris.org/view_bug.do?bug_id=4877567

Where are the comments, by the way?  (How hard is it to make the client
do this?)

> >
> > NFSv4 server should deny bogus OPEN_DOWNGRADE
> > http://bugs.opensolaris.org/view_bug.do?bug_id=4877573
> 
> Hmmm...if that's really the agreed upon behavior, I must say it's quite
> a shame that nobody bothered to fix the spec - not even in NFSv4.1.

NFSv4.1 actually expands on this a bit:

   After checking for valid values of share_access and share_deny, the
   server replaces the current access and deny modes on the file with
   share_access and share_deny subject to the following constraints:

	o  The bits in share_access SHOULD equal the union of the
	share_access bits (not including OPEN4_SHARE_WANT_* bits)
	specified for some subset of the OPENs in effect for the current
	open-owner on the current file.

	o  The bits in share_deny SHOULD equal the union of the
	share_deny bits specified for some subset of the OPENs in effect
	for the current open-owner on the current file.

   If the above constraints are not respected, the server SHOULD return
   the error NFS4ERR_INVAL.
  
> Also, the fact that the Solaris bugs have been around for five years
> makes it seem like they'll never be fixed.

But, yeah, it's unfortunate if a server has to ignore the final SHOULD
above in order to interoperating with any existing Solaris client.

--b.

> 
> I feel compelled to ask the folks on the IETF list what the right
> behavior should be.  Any comments from nfsv4 at ietf.org about what
> the right behavior is supposed to be here?
> 
> THanks
> --macko
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4