Linux-NFS Archive on lore.kernel.org
 help / color / Atom feed
From: Su Yanjun <suyj.fnst@cn.fujitsu.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: <linux-nfs@vger.kernel.org>, <dang@redhat.com>,
	<ffilzlnx@mindspring.com>
Subject: Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
Date: Fri, 12 Jul 2019 10:27:14 +0800
Message-ID: <b5ec42ea-7f50-0920-5794-32c379681225@cn.fujitsu.com> (raw)
In-Reply-To: <20190710000855.GE1536@fieldses.org>

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

      reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b5ec42ea-7f50-0920-5794-32c379681225@cn.fujitsu.com \
    --to=suyj.fnst@cn.fujitsu.com \
    --cc=bfields@fieldses.org \
    --cc=dang@redhat.com \
    --cc=ffilzlnx@mindspring.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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