All of lore.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 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.