[AFS3-std] Proposal: Extension of RXAFS_SetLock to support LockUpgrade and LockDowngrade

[Jeffrey Hutzelman]

On Saturday, February 25, 2006 12:23:33 AM -0500 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> Extending the existing RPC is safe to do because the existing
> implementations currently return EINVAL for these values.

I was wondering about this, since you'd want to use essentially the same 
approach to add support for mandatory locking (new operations for acquiring 
mandatory locks).


> The semantics of the new operations are as follows:
>
>   LockUpgrade - if there is only one lock issued and it is of
>   type "Read", then change the lock type to "Write" and return
>   success.  Otherwise, return EAGAIN.
>
>   LockDowngrade - if there is only one lock issued and it is of
>   type "Write", then change the lock type to "Read" and return
>   success.  Otherwise, return EAGAIN.

You are confusing protocol semantics with implementation behavior.  The 
current implementation happens not to remember who is actually holding 
locks, and so permits one client to release a lock that was acquired by 
another.  However, that is an implementation artifact, not something we 
should carve in stone for new operations.

The upgrade and downgrade operations should be defined to require that the 
correct type of lock already be held by the caller; if this is not the case 
the results are undefined - depending on the lock state, the server may 
return EAGAIN or some other error, or it may return success after changing 
the lock state in some undefined way.

The locking operations should only be defined to return EAGAIN in cases 
where you would ordinarily expect the operation to block - that is, if 
someone else holds a conflicting lock.  These operations should not return 
EAGAIN on an attempt to downgrade on a file for which there are only read 
locks, or on an attempt to upgrade or downgrade on a file on which there 
are currently no locks.

Also, these operations can presumably return EACCES in cases where the 
caller is not permitted to acquire the requested lock type.


> In both cases, a successful completion of the operation updates
> the lock issuance time to the current time.


> In order to avoid the need to issue try the new operations and
> fallback to the old release and lock approach, a Capability flag
> VICED_CAPABILITY_LOCK_UPGRADES will be created using a number assigned
> by registrar@grand.central.org.

Why is a capability necessary in this case?


[[ A general note:  For those who do not know, registrar@grand.central.org 
is me.  However, when I comment on proposals involving registering new 
procedure numbers or other values (as above), I do so as an individual.  If 
there is consensus that a value is needed, I will not refuse to register it 
on the grounds that I don't like the proposal. ]


-- Jeff