linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: calum.mackay@oracle.com
Cc: bfields@fieldses.org, ffilzlnx@mindspring.com,
	linux-nfs@vger.kernel.org, Frank Filz <ffilz@redhat.com>
Subject: [pynfs PATCH v2 5/5] LOCK24: fix the lock_seqid in second lock request
Date: Mon, 13 Mar 2023 07:24:01 -0400	[thread overview]
Message-ID: <20230313112401.20488-6-jlayton@kernel.org> (raw)
In-Reply-To: <20230313112401.20488-1-jlayton@kernel.org>

This test currently fails against Linux nfsd, but I think it's the test
that's wrong. It basically does:

open for read
read lock
unlock
open upgrade
write lock

The write lock above is sent with a lock_seqid of 0, which is wrong.
RFC7530/16.10.5 says:

   o  In the case in which the state has been created and the [new
      lockowner] boolean is true, the server rejects the request with the
      error NFS4ERR_BAD_SEQID.  The only exception is where there is a
      retransmission of a previous request in which the boolean was
      true.  In this case, the lock_seqid will match the original
      request, and the response will reflect the final case, below.

Since the above is not a retransmission, knfsd is correct to reject
this call. This patch fixes the open_sequence object to track the lock
seqid and set it correctly in the LOCK request.

With this, LOCK24 passes against knfsd.

Cc: Frank Filz <ffilz@redhat.com>
Fixes: 4299316fb357 (Add LOCK24 test case to test open uprgade/downgrade scenario)
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 nfs4.0/servertests/st_lock.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/nfs4.0/servertests/st_lock.py b/nfs4.0/servertests/st_lock.py
index 468672403ffe..9d650ab017b9 100644
--- a/nfs4.0/servertests/st_lock.py
+++ b/nfs4.0/servertests/st_lock.py
@@ -886,6 +886,7 @@ class open_sequence:
         self.client = client
         self.owner = owner
         self.lockowner = lockowner
+        self.lockseqid = 0
     def open(self, access):
         self.fh, self.stateid = self.client.create_confirm(self.owner,
 						access=access,
@@ -900,14 +901,17 @@ class open_sequence:
         self.client.close_file(self.owner, self.fh, self.stateid)
     def lock(self, type):
         res = self.client.lock_file(self.owner, self.fh, self.stateid,
-                    type=type, lockowner=self.lockowner)
+                                    type=type, lockowner=self.lockowner,
+                                    lockseqid=self.lockseqid)
         check(res)
         if res.status == NFS4_OK:
             self.lockstateid = res.lockid
+            self.lockseqid += 1
     def unlock(self):
         res = self.client.unlock_file(1, self.fh, self.lockstateid)
         if res.status == NFS4_OK:
             self.lockstateid = res.lockid
+            self.lockseqid += 1
 
 def testOpenUpgradeLock(t, env):
     """Try open, lock, open, downgrade, close
-- 
2.39.2


  parent reply	other threads:[~2023-03-13 11:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13 11:23 [pynfs PATCH v2 0/5] An assortment of pynfs patches Jeff Layton
2023-03-13 11:23 ` [pynfs PATCH v2 1/5] nfs4.0: add a retry loop on NFS4ERR_DELAY to compound function Jeff Layton
2023-03-13 11:23 ` [pynfs PATCH v2 2/5] examples: add a new example localhost_helper.sh script Jeff Layton
2023-03-13 11:23 ` [pynfs PATCH v2 3/5] nfs4.0/testserver.py: don't return an error when tests fail Jeff Layton
2023-03-13 11:24 ` [pynfs PATCH v2 4/5] testserver.py: add a new (special) "everything" flag Jeff Layton
2023-03-13 11:24 ` Jeff Layton [this message]
2023-03-13 18:51   ` [pynfs PATCH v2 5/5] LOCK24: fix the lock_seqid in second lock request Frank Filz
2023-03-13 21:23     ` Jeff Layton
2023-04-13 18:35     ` Calum Mackay
2023-04-14 14:41       ` Frank Filz
2023-04-14 17:24         ` Calum Mackay
2023-03-28 13:23   ` Petr Vorel
2023-03-13 16:39 ` [pynfs PATCH v2 0/5] An assortment of pynfs patches Calum Mackay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230313112401.20488-6-jlayton@kernel.org \
    --to=jlayton@kernel.org \
    --cc=bfields@fieldses.org \
    --cc=calum.mackay@oracle.com \
    --cc=ffilz@redhat.com \
    --cc=ffilzlnx@mindspring.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).