linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benny Halevy <bhalevy@tonian.com>
To: tao.peng@emc.com
Cc: Trond.Myklebust@netapp.com, bergwolf@gmail.com,
	gusev.vitaliy@nexenta.com, gusev.vitaliy@gmail.com,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfs: fix inifinite loop at nfs4_layoutcommit_release
Date: Wed, 14 Sep 2011 08:46:58 +0200	[thread overview]
Message-ID: <4E704DE2.1030308@tonian.com> (raw)
In-Reply-To: <F19688880B763E40B28B2B462677FBF805C3299F96@MX09A.corp.emc.com>

On 2011-09-13 10:09, tao.peng@emc.com wrote:
> Hi, Trond,
>> -----Original Message-----
>> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org]
>> On Behalf Of Trond Myklebust
>> Sent: Tuesday, September 13, 2011 5:11 AM
>> To: Benny Halevy
>> Cc: Peng Tao; Peng, Tao; gusev.vitaliy@nexenta.com; gusev.vitaliy@gmail.com;
>> linux-nfs@vger.kernel.org
>> Subject: Re: [PATCH] nfs: fix inifinite loop at nfs4_layoutcommit_release
>>
>> On Mon, 2011-09-12 at 13:31 -0700, Benny Halevy wrote:
>>> On 2011-09-12 07:56, Peng Tao wrote:
>>>>> The layout segments are not really in use while in LAYOUTCOMMIT.
>>>>> We only need to get the stateid right with respect to concurrent layout recalls.
>>>> LAYOUTCOMMIT takes lseg reference to mark them as in use so that
>>>> layoutrecall cannot free them.
>>>>
>>>
>>> And if layoutrecall would have freed layout segments during layoutcommit,
>>> what is your specific concern?
>>
>> That layoutcommit is supposed to return NFS4ERR_BAD_LAYOUT in that case
>> according to section 18.42.3 of RFC5661. I can't find anything in the
>> errata that changes that requirement.
> Do you mean that if client sends layoutcommit at the same time as server sends layoutrecall for overlapped range, then
> server must reject layoutcommit with NFS4ERR_BADLAYOUT when receiving layoutcommit?
> 
> RFC5661 section 18.42.3 says:
>    If the layout identified in the arguments does not exist, the error
>    NFS4ERR_BADLAYOUT is returned.  The layout being committed may also
>    be rejected if it does not correspond to an existing layout with an
>    iomode of LAYOUTIOMODE4_RW.
> 
> IMHO, in the above case, server cannot decide if the layout exists until client returns response to layoutrecall.

Right, unless the server revokes the layout, but then there are also other consequences
like SEQ4_STATUS_RECALLABLE_STATE_REVOKED.

Benny

> But I can't find
> any requirement in RFC5661 that server must wait for layoutrecall's response before processing layoutcommit.
> 
> Thanks,
> Tao

  reply	other threads:[~2011-09-14  6:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-28  6:22 [PATCH] nfs: fix inifinite loop at nfs4_layoutcommit_release Vitaliy Gusev
2011-09-06 19:29 ` Trond Myklebust
2011-09-06 22:13   ` Vitaliy Gusev
2011-09-06 22:32     ` Trond Myklebust
2011-09-08 10:21       ` tao.peng
2011-09-08 12:01         ` Myklebust, Trond
2011-09-08 15:00           ` Peng Tao
2011-09-08 17:05             ` Myklebust, Trond
2011-09-09  3:11               ` tao.peng
2011-09-09 18:20                 ` Trond Myklebust
2011-09-10  7:14                   ` Benny Halevy
2011-09-12 14:56                     ` Peng Tao
2011-09-12 20:31                       ` Benny Halevy
2011-09-12 21:10                         ` Trond Myklebust
2011-09-13  7:50                           ` Benny Halevy
2011-09-13  8:32                             ` tao.peng
2011-09-14  6:43                               ` Benny Halevy
2011-09-14  7:53                                 ` tao.peng
     [not found]                                   ` <F19688880B763E40B28B2B462677FBF805C3F7A911-AYrsSIZi/B2B3McK65YKY9BPR1lH4CV8@public.gmane.org>
2011-09-14 13:20                                     ` Benny Halevy
2011-09-13  8:09                           ` tao.peng
2011-09-14  6:46                             ` Benny Halevy [this message]
2011-09-13  7:02                         ` tao.peng
2011-09-13  7:54                           ` Benny Halevy
2011-09-12 14:48                   ` Peng Tao
2011-09-08 10:00     ` tao.peng
2011-09-08 13:02       ` Vitaliy Gusev
2011-09-08 15:09         ` Peng Tao
2011-09-09 17:46           ` Vitaliy Gusev
2011-09-12 14:42             ` Peng Tao

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=4E704DE2.1030308@tonian.com \
    --to=bhalevy@tonian.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bergwolf@gmail.com \
    --cc=gusev.vitaliy@gmail.com \
    --cc=gusev.vitaliy@nexenta.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tao.peng@emc.com \
    /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;
as well as URLs for NNTP newsgroup(s).