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

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

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?
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
>