Linux-NFS Archive on lore.kernel.org
 help / color / Atom feed
* [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

* Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
  2019-07-03  1:34 [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7 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

* 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-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 14:45     ` Frank Filz
@ 2019-07-09  5:27       ` Su Yanjun
  2019-07-10  0:08         ` J. Bruce Fields
                           ` (2 more replies)
  0 siblings, 3 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-09  5:27       ` Su Yanjun
@ 2019-07-10  0:08         ` J. Bruce Fields
  2019-07-12  2:27           ` Su Yanjun
  2019-07-29  1:54         ` [PATCH] CACHE: Fix test script as delegation being introduced Su Yanjun
  2019-08-06  8:23         ` [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7 Su Yanjun
  2 siblings, 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-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: [PATCH] CACHE: Fix test script as delegation being introduced
  2019-07-09  5:27       ` Su Yanjun
  2019-07-10  0:08         ` J. Bruce Fields
@ 2019-07-29  1:54         ` Su Yanjun
  2019-07-29 14:11           ` Olga Kornievskaia
  2019-08-06  8:23         ` [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7 Su Yanjun
  2 siblings, 1 reply; 12+ messages in thread
From: Su Yanjun @ 2019-07-29  1:54 UTC (permalink / raw)
  To: bfields; +Cc: linux-nfs

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




^ 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-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: [PATCH] CACHE: Fix test script as delegation being introduced
  2019-07-29  1:54         ` [PATCH] CACHE: Fix test script as delegation being introduced Su Yanjun
@ 2019-07-29 14:11           ` Olga Kornievskaia
  0 siblings, 0 replies; 12+ messages in thread
From: Olga Kornievskaia @ 2019-07-29 14:11 UTC (permalink / raw)
  To: Su Yanjun; +Cc: J. Bruce Fields, linux-nfs, Jorge Mora

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

^ 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-29  1:54         ` [PATCH] CACHE: Fix test script as delegation being introduced Su Yanjun
@ 2019-08-06  8:23         ` Su Yanjun
  2 siblings, 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

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 --
2019-07-03  1:34 [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7 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-07-29  1:54         ` [PATCH] CACHE: Fix test script as delegation being introduced Su Yanjun
2019-07-29 14:11           ` Olga Kornievskaia
2019-08-06  8:23         ` [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7 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 linux-nfs@archiver.kernel.org
	public-inbox-index linux-nfs


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