Bruce, The following patches implement the first phase in preparation for reducing the scope in we which we hold the state lock mutex. [RFC 01/11] nfsd: introduce nfs4_client state [RFC 02/11] nfsd: mark client state as expired in expire_client [RFC 03/11] nfsd: introduce get_nfs4_client [RFC 04/11] nfsd: mark client for renew [RFC 05/11] nfsd: skip clients marked for renewal [RFC 06/11] nfsd41: no need to hold the state lock around mark_client_for_renew the patches above use an atomic cl_state field to manage the nfs4_client expire vs. renew state so this can be done outside the state lock. [RFC 07/11] nfsd: rename recall_lock to deleg_lock [RFC 08/11] nfsd: use deleg_lock to protect dl_perfile and dl_perclnt [RFC 09/11] nfsd: get a reference count on the delgation while outside of the deleg_lock [RFC 10/11] nfsd: close delegation only on last reference [RFC 11/11] nfsd: refactor unhash_delegation The patches above augment the use of the recall_lock spinlock (and rename it to deleg_lock) and grab a reference count on the delegation structure while not protected by the deleg_lock. The delegation's respective file will be closed only on last dereference, so the deleg structure could be used safely while not holding the state_lock and potentially in parallel to expire_client being called (and unhashing the delegation) The next steps I see are: 1. use a spinlock for traversing the nfs4_client hash lists 2. use a spinlock for traversing the nfs4_stateowner lists Eventually, reducing the state_lock scope for complex state changes requiring the coordination of state across multiple lists and involving blocking ops (e.g. allocation, manipulating clid_dir) in particular there should be no need to hold the state lock for expire_client. Benny -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
