Hi, Frank
We modified the case according to Calum Mackay's suggestion (set the
parameter lk_is_new in the second lock to FALSE)
and the test result passed.
But we don't know if this modification violates the test intent.
Can you tell us your test intent?
Because our email system has some problem so i copy Calum Mackay's
reply here.
From: Calum Mackay @ 2019-07-29 13:12 UTC (permalink / raw)
To: Su Yanjun, J. Bruce Fields; +Cc: calum.mackay, linux-nfs, dang,
ffilzlnx
hi, I don't think you would expect an unlock to delete the lock owner:
the client may want to do further locking with this lock owner (without
the lk_is_new bit set).
The server would delete the LO when the client sends a
RELEASE_LOCKOWNER, or when the lease is expired, if it doesn't.
cheers,
calum.
在 2019/7/9 13:27, Su Yanjun 写道:
Hi Bruce
在 2019/7/8 22:45, Frank Filz 写道:
Yea, sorry, I totally missed this, but it does look like it's a
Kernel nfsd
Any suggestions?
issue.
Frank
-----Original Message-----
From: Daniel Gryniewicz [mailto:dang@xxxxxxxxxx]
Sent: Monday, July 8, 2019 6:49 AM
To: Su Yanjun <suyj.fnst@xxxxxxxxxxxxxx>; ffilzlnx@xxxxxxxxxxxxxx
Cc: linux-nfs@xxxxxxxxxxxxxxx
Subject: Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in
5.2.0-rc7
Is this running knfsd or Ganesha as the server? If it's Ganesha, the
question
would be better asked on the Ganesha Devel list
devel@xxxxxxxxxxxxxxxxxxxxx
If it's knfsd, than Frank isn't the right person to ask.
We are using the knfsd.
Daniel
On 7/7/19 10:20 PM, Su Yanjun wrote:
Ang ping?
在 2019/7/3 9:34, Su Yanjun 写道:
Hi Frank
We tested the pynfs of NFSv4.0 on the latest version of the kernel
(5.2.0-rc7).
I encountered a problem while testing st_lock.testOpenUpgradeLock.
The problem is now as follows:
**************************************************
LOCK24 st_lock.testOpenUpgradeLock : FAILURE
OP_LOCK should return NFS4_OK, instead got
NFS4ERR_BAD_SEQID
**************************************************
Is this normal?
The case is as follows:
Def testOpenUpgradeLock(t, env):
"""Try open, lock, open, downgrade, close
FLAGS: all lock
CODE: LOCK24
"""
c= env.c1
C.init_connection()
Os = open_sequence(c, t.code, lockowner="lockowner_LOCK24")
Os.open(OPEN4_SHARE_ACCESS_READ)
Os.lock(READ_LT)
Os.open(OPEN4_SHARE_ACCESS_WRITE)
Os.unlock()
Os.downgrade(OPEN4_SHARE_ACCESS_WRITE)
Os.lock(WRITE_LT)
Os.close()
After investigation, there was an error in unlock->lock. When
unlocking, the lockowner of the file was not released, causing an
error when locking again.
Will nfs4.0 support 1) open-> 2) lock-> 3) unlock-> 4) lock this
function?
