On Wed, 21 May 2014 12:05:24 -0400 "J. Bruce Fields" <[email protected]> wrote:
> From: "J. Bruce Fields" <[email protected]> > > The nfsv4 state code has always assumed a one-to-one correspondance > between lock stateid's and lockowners even if it appears not to in some > places. > > We may actually change that, but for now when FREE_STATEID releases a > lock stateid it also needs to release the parent lockowner. > > Symptoms were a subsequent LOCK crashing in find_lockowner_str when it > calls same_lockowner_ino on a lockowner that unexpectedly has an empty > so_stateids list. > > Cc: [email protected] > Signed-off-by: J. Bruce Fields <[email protected]> > --- > fs/nfsd/nfs4state.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c > index 32b699b..89e4240 100644 > --- a/fs/nfsd/nfs4state.c > +++ b/fs/nfsd/nfs4state.c > @@ -3717,9 +3717,16 @@ out: > static __be32 > nfsd4_free_lock_stateid(struct nfs4_ol_stateid *stp) > { > - if (check_for_locks(stp->st_file, lockowner(stp->st_stateowner))) > + struct nfs4_lockowner *lo = lockowner(stp->st_stateowner); > + > + if (check_for_locks(stp->st_file, lo)) > return nfserr_locks_held; > - release_lock_stateid(stp); > + /* > + * Currently there's a 1-1 lock stateid<->lockowner > + * correspondance, and we have to delete the lockowner when we > + * delete the lock stateid: > + */ > + unhash_lockowner(lo); Shouldn't this be release_lockowner(lo) ? If not, what's going to free the lockowner afterward? > return nfs_ok; > } > -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
