Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?










[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux