Subject: [nfsv4] use of NFS4ERR_ADMIN_REVOKED

From: [email-masked]
Date: Sun, 26 Sep 2004 15:20:15 -0400 (EDT)

In sec. 12:
NFS4ERR_ADMIN_REVOKED Due to andministrator intervention, the
	lockowner's record locks, share reservations, and delegations
	have been revoked by the server.

The above statement seems to suggest that the revocation is related to
a lockowner, but there are other places in the RFC that seem to imply
otherwise. For example, Renew can return NFS4ERR_ADMIN_REVOKED although
it takes a clientid and not a stateid. Also, a delegation isn't really
related to a lockowner, although it is initially issued due to an Open
associated with an open/lockowner.

The only other place I could find that discusses this in the RFC (para. 4
of sec. 8.8), doesn't seem to clarify this, although it does indication
that the revocation may only apply to one lockowner.
As such, here is what I'm currently implementing w.r.t. returning
NFS4ERR_ADMIN_REVOKED and am wondering if I'm off track yet again:-)
I have two type of revocations:
1 - all state for a client, after which the server returns
    NFS4ERR_ADMIN_REVOKED for all routines that can do so for that
    clientid and any associated stateid. (Close, Lock, LockU, Open,
    OpenConfirm, OpenDowngrade, Read, Setattr, Write, ReleaseLockOwner)
    It seems slightly strange that LockT isn't allowed to return it,
    but I went with "assume all locks are now from conflicting clients,
    since that client is revoked" and then test for conflicts.

    After the lease expires, the client goes away and further use of the
    clientid or associated stateids becomes NFS4ERR_EXPIRED. (Does this
    sound correct or should the Renew do a renewal even though it returns
    NFS4ERR_ADMIN_REVOKED.)
   * I can only see this being used when a client is somehow misbehaving
     and causing resource exhaustion or similar.

2 - byte range lock owner for a given stateid (which implies the associated
    clientid). For this case, the error would only be returned for Ops
    that used that stateid and NOT ones using the associated clientid,
    such as Renew. (Does that make sense, or should Renew return the
    error in this case?) It would do this persistently, until the lockowner
    state went away, via either a ReleaseLockOwner or a Close on the
    associated Open.

2a - open_owner (which implies all associated stateids for Opens and
    lockowners associated with those Opens). For this case, the error
    would be returned for all Ops using all of those stateids, but NOT
    Renew (same as 2). At some point, the OpenOwner would be released,
    since it has no Opens and the stateids would get NFS4ERR_EXPIRED after
    that. This one is problematic, in that it isn't obvious how long the
    OpenOwner with revoked flag set needs to persist?

    Alternatively, I could hold onto the OpenOwner until Close is done
    on all the associated Opens. This would guarantee that the client
    sees NFS4ERR_ADMIN_REVOKED, but also requires that the client bother
    to Close any Open who's stateid gets a NFS4ERR_ADMIN_REVOKED instead
    of just assuming it is no longer usable. (I may have missed it, but
    I can't see this spelled out in the RFC.)

Thanks in advance for any comments, rick

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