On Tue, 2014-02-18 at 10:36 -0500, andros@xxxxxxxxxx wrote:
> From: Andy Adamson <andros@xxxxxxxxxx>
>
> Do not return an error when nfs4_copy_delegation_stateid succeeds.
>
> Signed-off-by: Andy Adamson <andros@xxxxxxxxxx>
> ---
> fs/nfs/nfs4state.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index ba18958..1cfde97 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -1120,8 +1120,11 @@ int nfs4_select_rw_stateid(nfs4_stateid *dst, struct nfs4_state *state,
> if (ret == -EIO)
> /* A lost lock - don't even consider delegations */
> goto out;
> - if (nfs4_copy_delegation_stateid(dst, state->inode, fmode))
> + /* returns true if delegation stateid found and copied */
> + if (nfs4_copy_delegation_stateid(dst, state->inode, fmode)) {
> + ret = 0;
> goto out;
> + }
> if (ret != -ENOENT)
> /* nfs4_copy_delegation_stateid() didn't over-write
> * dst, so it still has the lock stateid which we now
Ouch! That looks like it would trigger looping in both the read and
write code when we're holding a delegation. Is that what you end up
seeing?
It looks like it was introduced by commit ef1820f9be27b...
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
--
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
