From: "Frank Filz" <ffilzlnx@mindspring.com>
To: <linux-nfs@vger.kernel.org>
Cc: "'Calum Mackay'" <calum.mackay@oracle.com>,
"'Ofir Vainshtein'" <ofirvins@google.com>
Subject: PYNFS LOCK20 Blocking Lock Test Case
Date: Tue, 12 Aug 2025 09:55:21 -0700 [thread overview]
Message-ID: <01d001dc0ba9$e4cb0080$ae610180$@mindspring.com> (raw)
I believe this test case is wrong, relevant text from RFC:
Some clients require the support of blocking locks. The NFSv4
protocol must not rely on a callback mechanism and therefore is
unable to notify a client when a previously denied lock has been
granted. Clients have no choice but to continually poll for the
lock. This presents a fairness problem. Two new lock types are
added, READW and WRITEW, and are used to indicate to the server that
the client is requesting a blocking lock. The server should maintain
an ordered list of pending blocking locks. When the conflicting lock
is released, the server may wait the lease period for the first
waiting client to re-request the lock. After the lease period
expires, the next waiting client request is allowed the lock.
Test case:
# Standard owner opens and locks a file
fh1, stateid1 = c.create_confirm(t.word(), deny=OPEN4_SHARE_DENY_NONE)
res1 = c.lock_file(t.word(), fh1, stateid1, type=WRITE_LT)
check(res1, msg="Locking file %s" % t.word())
# Second owner is denied a blocking lock
file = c.homedir + [t.word()]
fh2, stateid2 = c.open_confirm(b"owner2", file,
access=OPEN4_SHARE_ACCESS_BOTH,
deny=OPEN4_SHARE_DENY_NONE)
res2 = c.lock_file(b"owner2", fh2, stateid2,
type=WRITEW_LT, lockowner=b"lockowner2_LOCK20")
check(res2, NFS4ERR_DENIED, msg="Conflicting lock on %s" % t.word())
sleeptime = c.getLeaseTime() // 2
# Wait for queued lock to timeout
for i in range(3):
env.sleep(sleeptime, "Waiting for queued blocking lock to timeout")
res = c.compound([op.renew(c.clientid)])
check(res, [NFS4_OK, NFS4ERR_CB_PATH_DOWN])
# Standard owner releases lock
res1 = c.unlock_file(1, fh1, res1.lockid)
check(res1)
# Third owner tries to butt in and steal lock second owner is waiting
for
# Should work, since second owner let his turn expire
file = c.homedir + [t.word()]
fh3, stateid3 = c.open_confirm(b"owner3", file,
access=OPEN4_SHARE_ACCESS_BOTH,
deny=OPEN4_SHARE_DENY_NONE)
res3 = c.lock_file(b"owner3", fh3, stateid3,
type=WRITEW_LT, lockowner=b"lockowner3_LOCK20")
check(res3, msg="Grabbing lock after another owner let his 'turn'
expire")
Note that the RFC indicated the client has one lease period AFTER the
conflicting lock is released to retry while the test case waits 1.5 lease
period after requesting the blocking lock before it releases the conflicting
lock...
Am I reading things right?
Thanks
Frank Filz
next reply other threads:[~2025-08-12 17:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-12 16:55 Frank Filz [this message]
2025-08-14 1:29 ` PYNFS LOCK20 Blocking Lock Test Case Calum Mackay
2025-08-21 17:30 ` Frank Filz
2025-08-21 17:41 ` Calum Mackay
2025-08-21 17:47 ` Frank Filz
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='01d001dc0ba9$e4cb0080$ae610180$@mindspring.com' \
--to=ffilzlnx@mindspring.com \
--cc=calum.mackay@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=ofirvins@google.com \
/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).