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

[Su Yanjun <suyj.fnst@cn.fujitsu.com>]

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@redhat.com]
>>>>> Sent: Monday, July 8, 2019 6:49 AM
>>>>> To: Su Yanjun <suyj.fnst@cn.fujitsu.com>; ffilzlnx@mindspring.com
>>>>> Cc: linux-nfs@vger.kernel.org
>>>>> 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@lists.nfs-ganesha.org
>>>>>
>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>