Any ping?
在 2019/7/12 10:27, Su Yanjun 写道:
在 2019/7/10 8:08, J. Bruce Fields 写道:
On Tue, Jul 09, 2019 at 01:27:31PM +0800, Su Yanjun wrote:
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.
I don't know. I'd probably want to check a packet trace first to make
completely sure I understand what's happening on the wire. It may be a
couple weeks before I get to this.
We capture the packets in attachment.
Through packet capture analysis, there is a parameter *new lock owner*
related.
When locking, if lock->lk_is_new is true (create new lock owner), it
will check lock owner's existence.
Below is the execution path.
nfsd4_lock:
if(lock->lk_is_new)
lstatus = lookup_or_create_lock_state(cstate, open_stp, lock,
&lock_stp, &new);
lookup_or_create_lock_state:
lo = find_lockowner_str(cl, &lock->lk_new_owner);
if(!lo) {
...
} else {
status = nfserr_bad_seqid;
}
find_lockowner_str will check lock owner from hash table.
In this case unlock doesnot delete existed lock owner from hash table
so when lock again it
returns error.
So my question is
1. Does each lock always need new lock owner?
2. In this case, unlock doesnot delete lock owner from hash table, is
it normal?
Thanks
--b.
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?
