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

[Calum Mackay <calum.mackay@oracle.com>]

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.

On 29/07/2019 8:49 am, Su Yanjun wrote:
> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>
> 
> 

-- 
Calum Mackay
Linux Kernel Engineering
Oracle Linux and Virtualisation