All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Su, Yanjun" <suyj.fnst@cn.fujitsu.com>
To: "ffilzlnx@mindspring.com" <ffilzlnx@mindspring.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"dang@redhat.com" <dang@redhat.com>,
	"calum.mackay@oracle.com" <calum.mackay@oracle.com>,
	"bfields@fieldses.org" <bfields@fieldses.org>
Subject: Re: [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7
Date: Thu, 4 Jun 2020 01:41:57 +0000	[thread overview]
Message-ID: <3de3748749ea47398f5dc4ab0abbebfa@G08CNEXMBPEKD05.g08.fujitsu.local> (raw)

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




             reply	other threads:[~2020-06-04  1:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04  1:41 Su, Yanjun [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-01-20  3:27 [Problem]testOpenUpgradeLock test failed in nfsv4.0 in 5.2.0-rc7 Su, Yanjun
2020-01-13  1:33 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

Reply instructions:

You may reply publicly 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=3de3748749ea47398f5dc4ab0abbebfa@G08CNEXMBPEKD05.g08.fujitsu.local \
    --to=suyj.fnst@cn.fujitsu.com \
    --cc=bfields@fieldses.org \
    --cc=calum.mackay@oracle.com \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.