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

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

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

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

[Su Yanjun]

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

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

[Daniel Gryniewicz]

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.

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

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

[Frank Filz]

Yea, sorry, I totally missed this, but it does look like it's a Kernel nfsd 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.
> 
> 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?
> >>
> >>
> >>
> >
> >

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

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

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

[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.

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

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

[Su Yanjun]

[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]


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



[-- Attachment #2: LOCK.CAP --]
[-- Type: image/cap, Size: 39997 bytes --]

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

[Su Yanjun]

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

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

[Calum Mackay]

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

Re: [PATCH] CACHE: Fix test script as delegation being introduced

[Su Yanjun]

Hi bruce.

Sorry for my late reply. Our mail system has some problem that ignores your reply.

I Get the reply by google seach.

We tested the option "clientaddr=0.0.0.0" and the test case also fails.

Thanks

On Mon, Apr 08, 2019 at 10:47:56AM +0800, Su Yanjun<suyj.fnst@cn.fujitsu.com>  wrote:
> When we run nfstest_cache with nfsversion=4, it fails.
> As i know nfsv4 introduces delegation, so nfstest_cache runs fail
> since nfsv4.
> 
> The test commandline is as below:
> ./nfstest_cache --nfsversion=4 -e /nfsroot --server 192.168.102.143
> --client 192.168.102.142 --runtest acregmax_data --verbose all
> 
> This patch adds compatible code for nfsv3 and nfsv4.
> When we test nfsv4, just use 'chmod' to recall delegation, then
> run the test. As 'chmod' will modify atime, so use 'noatime' mount option.

I don't think a chmod is a reliable way to recall delegations.

Maybe mount with "clientaddr=0.0.0.0"?  From the nfs man page:

	Can  specify a value of IPv4_ANY (0.0.0.0) or equivalent IPv6
	any address  which will  signal to the NFS server that this NFS
	client does not want delegations.

(I wonder if that documentation's still accurate for versions >= 4.1?)

--b.
> 
> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> ---
> test/nfstest_cache | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/test/nfstest_cache b/test/nfstest_cache
> index 0838418..a31d48f 100755
> --- a/test/nfstest_cache
> +++ b/test/nfstest_cache
> @@ -165,8 +165,13 @@ class CacheTest(TestUtil):
> fd = None
> attr = 'data' if data_cache else 'attribute'
> header = "Verify consistency of %s caching with %s on a file" %
> (attr, self.nfsstr())
> +
> # Mount options
> - mtopts = "hard,intr,rsize=4096,wsize=4096"
> + if self.nfsversion >= 4:
> + mtopts = "noatime,hard,intr,rsize=4096,wsize=4096"
> + else: + mtopts = "hard,intr,rsize=4096,wsize=4096"
> +
> if actimeo:
> header += " actimeo = %d" % actimeo
> mtopts += ",actimeo=%d" % actimeo
> @@ -216,6 +221,11 @@ class CacheTest(TestUtil):
> if fstat.st_size != dlen:
> raise Exception("Size of newly created file is %d, should have been
> %d" %(fstat.st_size, dlen))
> + if self.nfsversion >= 4:
> + # revoke delegation
> + self.dprint('DBG3', "revoke delegation")
> + self.clientobj.run_cmd('chmod +x %s' % self.absfile)
> +
> if acregmax:
> # Stat the unchanging file until acregmax is hit
> # each stat doubles the valid cache time
> 
> -- 
> 2.7.4
> 
>

Re: [PATCH] CACHE: Fix test script as delegation being introduced

[Olga Kornievskaia]

Hi Su,

For nfstest patches, you should cc nfstest maintainer (Jorge Mora
mora@netapp.com).

On Sun, Jul 28, 2019 at 9:56 PM Su Yanjun <suyj.fnst@cn.fujitsu.com> wrote:
>
> Hi bruce.
>
> Sorry for my late reply. Our mail system has some problem that ignores your reply.
>
> I Get the reply by google seach.
>
> We tested the option "clientaddr=0.0.0.0" and the test case also fails.
>
> Thanks
>
> On Mon, Apr 08, 2019 at 10:47:56AM +0800, Su Yanjun<suyj.fnst@cn.fujitsu.com>  wrote:
> > When we run nfstest_cache with nfsversion=4, it fails.
> > As i know nfsv4 introduces delegation, so nfstest_cache runs fail
> > since nfsv4.
> >
> > The test commandline is as below:
> > ./nfstest_cache --nfsversion=4 -e /nfsroot --server 192.168.102.143
> > --client 192.168.102.142 --runtest acregmax_data --verbose all
> >
> > This patch adds compatible code for nfsv3 and nfsv4.
> > When we test nfsv4, just use 'chmod' to recall delegation, then
> > run the test. As 'chmod' will modify atime, so use 'noatime' mount option.
>
> I don't think a chmod is a reliable way to recall delegations.
>
> Maybe mount with "clientaddr=0.0.0.0"?  From the nfs man page:
>
>         Can  specify a value of IPv4_ANY (0.0.0.0) or equivalent IPv6
>         any address  which will  signal to the NFS server that this NFS
>         client does not want delegations.
>
> (I wonder if that documentation's still accurate for versions >= 4.1?)
>
> --b.
> >
> > Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> > ---
> > test/nfstest_cache | 12 +++++++++++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/test/nfstest_cache b/test/nfstest_cache
> > index 0838418..a31d48f 100755
> > --- a/test/nfstest_cache
> > +++ b/test/nfstest_cache
> > @@ -165,8 +165,13 @@ class CacheTest(TestUtil):
> > fd = None
> > attr = 'data' if data_cache else 'attribute'
> > header = "Verify consistency of %s caching with %s on a file" %
> > (attr, self.nfsstr())
> > +
> > # Mount options
> > - mtopts = "hard,intr,rsize=4096,wsize=4096"
> > + if self.nfsversion >= 4:
> > + mtopts = "noatime,hard,intr,rsize=4096,wsize=4096"
> > + else: + mtopts = "hard,intr,rsize=4096,wsize=4096"
> > +
> > if actimeo:
> > header += " actimeo = %d" % actimeo
> > mtopts += ",actimeo=%d" % actimeo
> > @@ -216,6 +221,11 @@ class CacheTest(TestUtil):
> > if fstat.st_size != dlen:
> > raise Exception("Size of newly created file is %d, should have been
> > %d" %(fstat.st_size, dlen))
> > + if self.nfsversion >= 4:
> > + # revoke delegation
> > + self.dprint('DBG3', "revoke delegation")
> > + self.clientobj.run_cmd('chmod +x %s' % self.absfile)
> > +
> > if acregmax:
> > # Stat the unchanging file until acregmax is hit
> > # each stat doubles the valid cache time
> >
> > --
> > 2.7.4
> >
> >
>
>
>

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

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

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

[Su, Yanjun]

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

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

[Su, Yanjun]

Hi Frank

We haven't contacted for a long time. Let's sort out the problem. The details are as follows:

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

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.

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.
Can you tell me if this modification is correct？

And the previous discussion is here.
https://www.spinics.net/lists/linux-nfs/msg76061.html

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

[Su, Yanjun]

Any ping?

>Hi Frank

>We haven't contacted for a long time. Let's sort out the problem. The details are as follows:

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

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

>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.
>Can you tell me if this modification is correct？

>And the previous discussion is here.
>https://www.spinics.net/lists/linux-nfs/msg76061.html