On Fri, 17 Nov 2023, Jeff Layton wrote: > On Fri, 2023-11-17 at 13:18 +1100, NeilBrown wrote: > > This set adds a prequel series to my previous posting which addresses > > some locking problems around ->sc_type and splits that field into > > to separate fields: sc_type and sc_status. > > The recovation code is modified to accomodate these changed. > > > > Thanks > > NeilBrown > > > > [PATCH 1/9] nfsd: hold ->cl_lock for hash_delegation_locked() > > [PATCH 2/9] nfsd: avoid race after unhash_delegation_locked() > > [PATCH 3/9] nfsd: split sc_status out of sc_type > > [PATCH 4/9] nfsd: prepare for supporting admin-revocation of state > > [PATCH 5/9] nfsd: allow admin-revoked state to appear in > > [PATCH 6/9] nfsd: allow admin-revoked NFSv4.0 state to be freed. > > [PATCH 7/9] nfsd: allow lock state ids to be revoked and then freed > > [PATCH 8/9] nfsd: allow open state ids to be revoked and then freed > > [PATCH 9/9] nfsd: allow delegation state ids to be revoked and then > > > > Nice set. I like this overall. One (other) question: do we need to add > handling for revoking layout stateids as well? I guess so... I don't give much thought to layout stateids. They are used in LAYOUTGET LAYOUTCOMMIT LAYOUTRETURN. (it's seems odd that they aren't used in READ/WRITE....) I guess we need to drop the ref on ->ls_file and maybe unlock the vfs lease.... I wonder if I should just use ->sc_free for that. Maybe ->sc_free could take a 'revoke_only' arg which causes it to free resources but not free the stateid itself. Maybe that would make the code cleaner. NeilBrown > > I'll plan to pull this into my local branch for some testing over the > weekend. > -- > Jeff Layton <jlayton@xxxxxxxxxx> >
