public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Mi Jinlong <mijinlong@cn.fujitsu.com>
To: "Trond.Myklebust" <trond.myklebust@fys.uio.no>
Cc: NFSv3 list <linux-nfs@vger.kernel.org>,
	bfields@fieldses.org, mingo@elte.hu
Subject: [RFC][PATCH 0/3] nlm:Fix bug nlm cann't process retransmited request correctly
Date: Tue, 27 Oct 2009 11:22:41 +0800	[thread overview]
Message-ID: <4AE66781.1020608@cn.fujitsu.com> (raw)

 I found a bug when tested NLM. The case likes followed:

           client                          server
             |                                |
      step1  |           open file            |
      open   |------------------------------->|
             |              ok                |
             |<-------------------------------|
             |                                | step2
             |                             -> | <-  service nfslock sto=
p
             |                                |
             | WL1: write lock request{0, 0}  |
      step3  |------------------------------->|
      fcntl  |                                |=20
             |                                |
             |    WL1_re: WL1 retransmit      |
             |------------------------------->|
             |                                |
             |       WL1.reply   ENOLCK       |
             |<-------------------------------|
             |                                |
             |                                | step4
             |                             -> | <- service nfslock star=
t
             |                                |
             | WL2: write lock request{0, 0}  |
      step5  |------------------------------->|
      fcntl  |                                |
             |        WL1_re.reply OK         |
             |<-------------------------------|
             |       WL2.reply EBLOCKD        |
             |<-------------------------------|


   client can not acquire for write lock any more after step4.

 Reason:
     Server reply ENOLCK for WL1 to client because nfslock service stop=
ed, but it can not
   distinguish  retransmited request with normal request, so it reply O=
K for WL1_re to
   client after nfslock service start. But fcntl client called will ret=
urn when it receive
   WL1.reply, and WL2 can not get a equal svid to WL1_re=EF=BC=8Cso ser=
ver will reply EBLOCKD for
   it.

 Suggestion:

   I suggest add an DRC for NLM.
   There are three patchs followed:

   1. add an universal DRC to sunrpc, it will be used by those protocol
      which be built on sunrpc
      [0001-Add-an-universal-DRC-to-sunrpc.patch]

   2. add DRC to NLM using sunrpc's universal DRC
      [0002-Add-DRC-to-NLM-using-sunrpc-s-DRC.patch]

   3. modify the nfsd's DRC to use sunrpc's universal DRC
      [0003-Modify-the-nfsd-s-DRC-to-use-sunrpc-s-universal-DRC.patch]

--

 arch/parisc/kernel/sys_parisc32.c |    2 +-
 arch/s390/kernel/compat_linux.c   |    2 +-
 arch/sparc/kernel/sys_sparc32.c   |    2 +-
 fs/lockd/svc.c                    |   66 ++++++++
 fs/lockd/svc4proc.c               |   52 +++---
 fs/nfsd/Makefile                  |    2 +-
 fs/nfsd/nfs2acl.c                 |    2 +-
 fs/nfsd/nfs3acl.c                 |    2 +-
 fs/nfsd/nfs3proc.c                |    2 +-
 fs/nfsd/nfs4proc.c                |    2 +-
 fs/nfsd/nfs4state.c               |    2 +-
 fs/nfsd/nfscache.c                |  330 -----------------------------=
--------
 fs/nfsd/nfsctl.c                  |   10 +-
 fs/nfsd/nfsproc.c                 |    2 +-
 fs/nfsd/nfssvc.c                  |   13 +-
 fs/nfsd/stats.c                   |    9 +-
 include/linux/lockd/lockd.h       |    6 +
 include/linux/nfsd/cache.h        |   62 -------
 include/linux/nfsd/stats.h        |    3 -
 include/linux/sunrpc/drc.h        |   97 +++++++++++
 net/sunrpc/Makefile               |    2 +-
 net/sunrpc/drc.c                  |  326 +++++++++++++++++++++++++++++=
+++++++
 22 files changed, 553 insertions(+), 443 deletions(-) =20

--=20
Regards
Mi Jinlong


             reply	other threads:[~2009-10-27  3:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27  3:22 Mi Jinlong [this message]
2009-10-27  3:27 ` [RFC][PATCH 1/3] sunrpc:add an universal DRC to sunrpc Mi Jinlong
2009-10-27  3:30 ` [RFC][PATCH 2/3] nlm:add DRC to NLM using sunrpc's universal DRC Mi Jinlong
2009-10-27  3:31 ` [RFC][PATCH 3/3] nfsd:modify the nfsd's DRC to use " Mi Jinlong

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=4AE66781.1020608@cn.fujitsu.com \
    --to=mijinlong@cn.fujitsu.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=trond.myklebust@fys.uio.no \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox