From owner-svn-src-all@freebsd.org Sat Sep 26 23:05:39 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 62E2C3E371F; Sat, 26 Sep 2020 23:05:39 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzPX31RQJz4CnY; Sat, 26 Sep 2020 23:05:39 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0E31A2B66F; Sat, 26 Sep 2020 23:05:39 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 08QN5cYC080668; Sat, 26 Sep 2020 23:05:38 GMT (envelope-from rmacklem@FreeBSD.org) Received: (from rmacklem@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 08QN5cj4080667; Sat, 26 Sep 2020 23:05:38 GMT (envelope-from rmacklem@FreeBSD.org) Message-Id: <202009262305.08QN5cj4080667@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: rmacklem set sender to rmacklem@FreeBSD.org using -f From: Rick Macklem Date: Sat, 26 Sep 2020 23:05:38 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r366189 - head/sys/fs/nfsserver X-SVN-Group: head X-SVN-Commit-Author: rmacklem X-SVN-Commit-Paths: head/sys/fs/nfsserver X-SVN-Commit-Revision: 366189 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 23:05:39 -0000 Author: rmacklem Date: Sat Sep 26 23:05:38 2020 New Revision: 366189 URL: https://svnweb.freebsd.org/changeset/base/366189 Log: 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 Modified: head/sys/fs/nfsserver/nfs_nfsdstate.c Modified: head/sys/fs/nfsserver/nfs_nfsdstate.c ============================================================================== --- head/sys/fs/nfsserver/nfs_nfsdstate.c Sat Sep 26 21:47:11 2020 (r366188) +++ head/sys/fs/nfsserver/nfs_nfsdstate.c Sat Sep 26 23:05:38 2020 (r366189) @@ -1870,14 +1870,20 @@ tryagain: } if (!error) nfsrv_getowner(&stp->ls_open, new_stp, &lckstp); - if (lckstp) + if (lckstp) { /* - * I believe this should be an error, but it - * isn't obvious what NFSERR_xxx would be - * appropriate, so I'll use NFSERR_INVAL for now. + * For NFSv4.1 and NFSv4.2 allow an + * open_to_lock_owner when the lock_owner already + * exists. Just clear NFSLCK_OPENTOLOCK so that + * a new lock_owner will not be created. + * RFC7530 states that the error for NFSv4.0 + * is NFS4ERR_BAD_SEQID. */ - error = NFSERR_INVAL; - else + if ((nd->nd_flag & ND_NFSV41) != 0) + new_stp->ls_flags &= ~NFSLCK_OPENTOLOCK; + else + error = NFSERR_BADSEQID; + } else lckstp = new_stp; } else if (new_stp->ls_flags&(NFSLCK_LOCK|NFSLCK_UNLOCK)) { /*