summaryrefslogtreecommitdiffstats
path: root/fs/nfsd/nfs4state.c
diff options
context:
space:
mode:
authorNeilBrown <neilb@cse.unsw.edu.au>2005-07-08 02:59:21 +0200
committerLinus Torvalds <torvalds@g5.osdl.org>2005-07-08 03:24:09 +0200
commite66770cd7b0c36f28a2f6eb0957c0575ac8b3787 (patch)
treeee5bcf1ac04eac19c72fad96863bc7b0327a3f47 /fs/nfsd/nfs4state.c
parent[PATCH] nfsd4: seqid comments (diff)
downloadlinux-e66770cd7b0c36f28a2f6eb0957c0575ac8b3787.tar.xz
linux-e66770cd7b0c36f28a2f6eb0957c0575ac8b3787.zip
[PATCH] nfsd4: relax new lock seqid check
We're insisting that the lock sequence id field passed in the open_to_lockowner struct always be zero. This is probably thanks to the sentence in rfc3530: "The first request issued for any given lock_owner is issued with a sequence number of zero." But there doesn't seem to be any problem with allowing initial sequence numbers other than zero. And currently this is causing lock reclaims from the Linux client to fail. In the spirit of "be liberal in what you accept, conservative in what you send", we'll relax the check (and patch the Linux client as well). Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to '')
-rw-r--r--fs/nfsd/nfs4state.c5
1 files changed, 0 insertions, 5 deletions
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index f60bcad77f71..386daac508f5 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -2715,11 +2715,6 @@ nfsd4_lock(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct nfsd4_lock
goto out;
}
- /* is the new lock seqid presented by the client zero? */
- status = nfserr_bad_seqid;
- if (lock->v.new.lock_seqid != 0)
- goto out;
-
/* validate and update open stateid and open seqid */
status = nfs4_preprocess_seqid_op(current_fh,
lock->lk_new_open_seqid,