On Wed, 21 May 2014 12:05:24 -0400
"J. Bruce Fields" <bfields@xxxxxxxxxx> wrote:
> From: "J. Bruce Fields" <bfields@xxxxxxxxxx>
>
> 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: stable@xxxxxxxxxxxxxxx
> Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx>
> ---
> 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 <jlayton@xxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html