Linux-NFS Archive on lore.kernel.org
 help / color / Atom feed
* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
@ 2020-01-13  1:33 Su, Yanjun
  0 siblings, 0 replies; 12+ messages in thread
From: Su, Yanjun @ 2020-01-13  1:33 UTC (permalink / raw)
  To: ffilzlnx; +Cc: linux-nfs, dang, calum.mackay, bfields

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
@ 2020-01-20  3:27 Su, Yanjun
  0 siblings, 0 replies; 12+ messages in thread
From: Su, Yanjun @ 2020-01-20  3:27 UTC (permalink / raw)
  To: ffilzlnx; +Cc: linux-nfs, dang, calum.mackay, bfields

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




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-09  5:27       ` Su Yanjun
  2019-07-10  0:08         ` J. Bruce Fields
@ 2019-08-06  8:23         ` Su Yanjun
  1 sibling, 0 replies; 12+ messages in thread
From: Su Yanjun @ 2019-08-06  8:23 UTC (permalink / raw)
  To: ffilzlnx; +Cc: linux-nfs, dang, bfields, calum.mackay

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-29  7:49             ` Su Yanjun
@ 2019-07-29 13:12               ` Calum Mackay
  0 siblings, 0 replies; 12+ messages in thread
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.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-12  2:27           ` Su Yanjun
@ 2019-07-29  7:49             ` Su Yanjun
  2019-07-29 13:12               ` Calum Mackay
  0 siblings, 1 reply; 12+ messages in thread
From: Su Yanjun @ 2019-07-29  7:49 UTC (permalink / raw)
  To: J. Bruce Fields; +Cc: linux-nfs, dang, ffilzlnx

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-10  0:08         ` J. Bruce Fields
@ 2019-07-12  2:27           ` Su Yanjun
  2019-07-29  7:49             ` Su Yanjun
  0 siblings, 1 reply; 12+ messages in thread
From: Su Yanjun @ 2019-07-12  2:27 UTC (permalink / raw)
  To: J. Bruce Fields; +Cc: linux-nfs, dang, ffilzlnx

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-09  5:27       ` Su Yanjun
@ 2019-07-10  0:08         ` J. Bruce Fields
  2019-07-12  2:27           ` Su Yanjun
  2019-08-06  8:23         ` Su Yanjun
  1 sibling, 1 reply; 12+ messages in thread
From: J. Bruce Fields @ 2019-07-10  0:08 UTC (permalink / raw)
  To: Su Yanjun; +Cc: linux-nfs, dang, ffilzlnx

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-08 14:45     ` Frank Filz
@ 2019-07-09  5:27       ` Su Yanjun
  2019-07-10  0:08         ` J. Bruce Fields
  2019-08-06  8:23         ` Su Yanjun
  0 siblings, 2 replies; 12+ messages in thread
From: Su Yanjun @ 2019-07-09  5:27 UTC (permalink / raw)
  To: bfields; +Cc: linux-nfs, dang, ffilzlnx

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-08 13:48   ` Daniel Gryniewicz
@ 2019-07-08 14:45     ` Frank Filz
  2019-07-09  5:27       ` Su Yanjun
  0 siblings, 1 reply; 12+ messages in thread
From: Frank Filz @ 2019-07-08 14:45 UTC (permalink / raw)
  To: dang, Su Yanjun; +Cc: linux-nfs

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-08  2:20 ` Su Yanjun
@ 2019-07-08 13:48   ` Daniel Gryniewicz
  2019-07-08 14:45     ` Frank Filz
  0 siblings, 1 reply; 12+ messages in thread
From: Daniel Gryniewicz @ 2019-07-08 13:48 UTC (permalink / raw)
  To: Su Yanjun, ffilzlnx; +Cc: linux-nfs

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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-03  1:34 Su Yanjun
@ 2019-07-08  2:20 ` Su Yanjun
  2019-07-08 13:48   ` Daniel Gryniewicz
  0 siblings, 1 reply; 12+ messages in thread
From: Su Yanjun @ 2019-07-08  2:20 UTC (permalink / raw)
  To: ffilzlnx; +Cc: linux-nfs, linux-kernel

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
@ 2019-07-03  1:34 Su Yanjun
  2019-07-08  2:20 ` Su Yanjun
  0 siblings, 1 reply; 12+ messages in thread
From: Su Yanjun @ 2019-07-03  1:34 UTC (permalink / raw)
  To: ffilzlnx; +Cc: linux-nfs, linux-kernel

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?




^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-13  1:33 [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7 Su, Yanjun
  -- strict thread matches above, loose matches on Subject: below --
2020-01-20  3:27 Su, Yanjun
2019-07-03  1:34 Su Yanjun
2019-07-08  2:20 ` Su Yanjun
2019-07-08 13:48   ` Daniel Gryniewicz
2019-07-08 14:45     ` Frank Filz
2019-07-09  5:27       ` Su Yanjun
2019-07-10  0:08         ` J. Bruce Fields
2019-07-12  2:27           ` Su Yanjun
2019-07-29  7:49             ` Su Yanjun
2019-07-29 13:12               ` Calum Mackay
2019-08-06  8:23         ` Su Yanjun

Linux-NFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-nfs/0 linux-nfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nfs linux-nfs/ https://lore.kernel.org/linux-nfs \
		linux-nfs@vger.kernel.org
	public-inbox-index linux-nfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-nfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git