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

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

Any ping?

在 2019/8/6 16:23, Su Yanjun 写道:
> 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@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?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
>
>