All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Kirch <okir@suse.de>
To: Marc Eshel <eshel@almaden.ibm.com>
Cc: NFS@lists.sourceforge.net, nfs-admin@lists.sourceforge.net
Subject: Re: unlock during lockd recovery
Date: Wed, 24 Nov 2004 09:59:05 +0100	[thread overview]
Message-ID: <20041124085905.GC7108@suse.de> (raw)
In-Reply-To: <OF2DFFDFB5.4B33C70C-ON88256F55.006063CF-88256F55.00616D80@us.ibm.com>

On Tue, Nov 23, 2004 at 09:44:10AM -0800, Marc Eshel wrote:
> If the client application unlocks the lock before it was reclaimed than it
> should not be reclaimed.

The problem is that your lockd server would make assumptions about the
client's implementation; in particular, this would mandate that the client
prevents any regular NLM activity while it's in the middle of a reclaim.

However, the X/Open spec for NLM says about NLM_LOCK: "During the grace
period, the server will only accept locks with reclaim set to true."
So the client is free to assume that it's okay to keep on retransmitting
LOCK/UNLOCK request all along, without having to care about reclaim or not,
because the spec says the server will ignore them anyway.

Consider this scenario:

 -	Server tells client to start reclaim
 -	Client sends reclaim request for lock X
 -	RPC packet gets lost
 -	Application requests to unlock X
 -	Client calls server, server finds there's nothing to
 	unlock, ACKs the RPC call
 -	Client retransmits reclaim packet, server re-installs
 	the lock
 -	you have a stale lock

Olaf
-- 
Olaf Kirch     | Things that make Monday morning interesting, #2:
okir@suse.de   |        "We have 8,000 NFS mount points, why do we keep
---------------+ 	 running out of privileged ports?"


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

      reply	other threads:[~2004-11-24  8:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-11 19:12 lockd recovery not working on RH with 2.6 kernel Marc Eshel
2004-11-17 19:58 ` Steve Dickson
2004-11-18 16:52 ` Steve Dickson
2004-11-19 16:34   ` Trond Myklebust
2004-11-19 17:50     ` Steve Dickson
2004-11-19 20:24       ` Trond Myklebust
2004-11-19 20:27         ` Trond Myklebust
2004-11-19 21:40         ` Steve Dickson
2004-11-19 20:38       ` Steve Dickson
2004-11-23  0:45         ` unlock during lockd recovery Marc Eshel
2004-11-23  8:10           ` Olaf Kirch
2004-11-23 17:44             ` Marc Eshel
2004-11-24  8:59               ` Olaf Kirch [this message]

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=20041124085905.GC7108@suse.de \
    --to=okir@suse.de \
    --cc=NFS@lists.sourceforge.net \
    --cc=eshel@almaden.ibm.com \
    --cc=nfs-admin@lists.sourceforge.net \
    /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.