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?
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?
>
>
>
Is this running knfsd or Ganesha as the server? If it's Ganesha, the
question would be better asked on the Ganesha Devel list
[email protected]
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?
>>
>>
>>
>
>
Yea, sorry, I totally missed this, but it does look like it's a Kernel nfsd issue.
Frank
> -----Original Message-----
> From: Daniel Gryniewicz [mailto:[email protected]]
> Sent: Monday, July 8, 2019 6:49 AM
> To: Su Yanjun <[email protected]>; [email protected]
> Cc: [email protected]
> 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 [email protected]
>
> 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?
> >>
> >>
> >>
> >
> >
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:[email protected]]
>> Sent: Monday, July 8, 2019 6:49 AM
>> To: Su Yanjun <[email protected]>; [email protected]
>> Cc: [email protected]
>> 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
>> [email protected]
>>
>> 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?
>>>>
>>>>
>>>>
>>>
>
>
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:[email protected]]
> >>Sent: Monday, July 8, 2019 6:49 AM
> >>To: Su Yanjun <[email protected]>; [email protected]
> >>Cc: [email protected]
> >>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
> >>[email protected]
> >>
> >>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?
> >>>>
> >>>>
> >>>>
> >>>
> >
> >
>
在 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:[email protected]]
>>>> Sent: Monday, July 8, 2019 6:49 AM
>>>> To: Su Yanjun <[email protected]>; [email protected]
>>>> Cc: [email protected]
>>>> 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
>>>> [email protected]
>>>>
>>>> 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?
>>>>>>
>>>>>>
>>>>>>
>>>
>
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<[email protected]> 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 <[email protected]>
> ---
> 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
>
>
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:[email protected]]
>>>>> Sent: Monday, July 8, 2019 6:49 AM
>>>>> To: Su Yanjun <[email protected]>; [email protected]
>>>>> Cc: [email protected]
>>>>> 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
>>>>> [email protected]
>>>>>
>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
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:[email protected]]
>>>>>> Sent: Monday, July 8, 2019 6:49 AM
>>>>>> To: Su Yanjun <[email protected]>; [email protected]
>>>>>> Cc: [email protected]
>>>>>> 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
>>>>>> [email protected]
>>>>>>
>>>>>> 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
Hi Su,
For nfstest patches, you should cc nfstest maintainer (Jorge Mora
[email protected]).
On Sun, Jul 28, 2019 at 9:56 PM Su Yanjun <[email protected]> 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<[email protected]> 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 <[email protected]>
> > ---
> > 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
> >
> >
>
>
>
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:[email protected]]
>>> Sent: Monday, July 8, 2019 6:49 AM
>>> To: Su Yanjun <[email protected]>; [email protected]
>>> Cc: [email protected]
>>> 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
>>> [email protected]
>>>
>>> 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?
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
>
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:[email protected]]
>>>> Sent: Monday, July 8, 2019 6:49 AM
>>>> To: Su Yanjun <[email protected]>; [email protected]
>>>> Cc: [email protected]
>>>> 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
>>>> [email protected]
>>>>
>>>> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
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
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