]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Bjorn reported a problem where the Linux NFSv4.1 client is
authorrmacklem <rmacklem@FreeBSD.org>
Sat, 26 Sep 2020 23:05:38 +0000 (23:05 +0000)
committerrmacklem <rmacklem@FreeBSD.org>
Sat, 26 Sep 2020 23:05:38 +0000 (23:05 +0000)
commit9deadc11c4ac2282982d67a070d1bb984aece426
treee3831f1b8c47f80b8e15cb7c8603f6c4c913f2ff
parent00ca7875820d8c64afbeaed2139edccd4172fdbb
Bjorn reported a problem where the Linux NFSv4.1 client is
using an open_to_lock_owner4 when that lock_owner4 has already
been created by a previous open_to_lock_owner4. This caused the NFS server
to reply NFSERR_INVAL.

For NFSv4.0, this is an error, although the updated NFSv4.0 RFC7530 notes
that the correct error reply is NFSERR_BADSEQID (RFC3530 did not specify
what error to return).

For NFSv4.1, it is not obvious whether or not this is allowed by RFC5661,
but the NFSv4.1 server can handle this case without error.
This patch changes the NFSv4.1 (and NFSv4.2) server to handle multiple
uses of the same lock_owner in open_to_lock_owner so that it now correctly
interoperates with the Linux NFS client.
It also changes the error returned for NFSv4.0 to be NFSERR_BADSEQID.

Thanks go to Bjorn for diagnosing this and testing the patch.
He also provided a program that I could use to reproduce the problem.

Tested by: bj@cebitec.uni-bielefeld.de (Bjorn Fischer)
PR: 249567
Reported by: bj@cebitec.uni-bielefeld.de (Bjorn Fischer)
MFC after: 3 days
sys/fs/nfsserver/nfs_nfsdstate.c