The following is a revised proposal that incorporates the comments received in February.
------------------------------------------------------------------- The RXAFS_SetLock RPC currently supports four operations: %#define LockRead 0 %#define LockWrite 1 %#define LockExtend 2 %#define LockRelease 3 This set of operations do not provide the functionality necessary in order to safely support the upgrading of a read lock to the write lock and the downgrading of a write lock to a read lock. Currently, upgrades and downgrades are implemented in the afs client by dropping a lock and requesting the other type. Unfortunately, this creates a race condition which can result in the loss of the lock in its entirety. To remove the race condition two additional operations are proposed for the existing RXAFS_SetLock RPC: %#define LockUpgrade 4 %#define LockDowngrade 5 Extending the existing RPC is safe to do because the existing implementations currently return EINVAL for these values. The semantics of the new operations are as follows: LockUpgrade: if the client has been issued a "Read" lock and no other parties have been issued locks on the object, then change the lock type to "Write" and return success. If the client has already been issued a "Write" lock, then return EEXIST. If the client has not been issued any lock, then return ENOENT. If the client does not have permission to obtain a "Write" lock due to lack of PRSFS_WRITE or PRSFS_INSERT privileges, then return EACCES. Otherwise, return EAGAIN. LockDowngrade - if the client has been issued a "Write" lock, then change the lock type to "Read" and return success. If the client already has been issued a "Read" lock, then return EEXIST. If the client has not been issued any lock, then return ENOENT. If the client does not have permission to obtain a "Read" lock due to lack of PRSFS_LOCK privilege, then return EACCESS. Otherwise, return EAGAIN. Lock Lifetimes: Locks have a lifetime of five minutes in AFS. Both of the LockUpgrade and LockDowngrade operations reset the lock expiration timer upon success. 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 [EMAIL PROTECTED] Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
