All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mi Jinlong <mijinlong@cn.fujitsu.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: NFS <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] nfsd41: Deny new lock before RECLAIM_COMPLETE done
Date: Tue, 10 May 2011 17:17:45 +0800	[thread overview]
Message-ID: <4DC902B9.5060103@cn.fujitsu.com> (raw)
In-Reply-To: <20110427135422.GA1618@fieldses.org>

Hi Bruce,

 Sorry for so late to reply you.

J. Bruce Fields:
> On Wed, Apr 27, 2011 at 09:12:00AM +0800, Mi Jinlong wrote:
>> Before nfs41 client's RECLAIM_COMPLETE done, nfs server should 
>> deny it's new lock.
>>
>> Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
> 
> Is nfserr_grace the right error?  (Honest question, I haven't looked it
> up.)

  Yes, rfc5661 says:

  " Whenever a client establishes a new client ID and before it does the
    first non-reclaim operation that obtains a lock, it MUST send a
    RECLAIM_COMPLETE with rca_one_fs set to FALSE, even if there are no
    locks to reclaim.  If non-reclaim locking operations are done before
    the RECLAIM_COMPLETE, an NFS4ERR_GRACE error will be returned. "
 
> 
> Also I'd think this check should go in nfsd4_open: opens are also
> prohibited before RECLAIM_COMPLETE, and if we check there then we don't
> need to check here, as you have to have open state before you can do a
> lock.

  Agree with you, what about the following one??

-- 
----
thanks
Mi Jinlong
===============================

  reply	other threads:[~2011-05-10  9:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27  1:12 [PATCH] nfsd41: Deny new lock before RECLAIM_COMPLETE done Mi Jinlong
2011-04-27 13:54 ` J. Bruce Fields
2011-05-10  9:17   ` Mi Jinlong [this message]
2011-05-10  9:23     ` 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=4DC902B9.5060103@cn.fujitsu.com \
    --to=mijinlong@cn.fujitsu.com \
    --cc=bfields@fieldses.org \
    --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.