All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benjamin Coddington" <bcodding@redhat.com>
To: "Trond Myklebust" <trondmy@primarydata.com>
Cc: "anna.schumaker@netapp.com" <anna.schumaker@netapp.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 3/3] NFSv4.1: Detect and retry after OPEN and CLOSE/DOWNGRADE race
Date: Tue, 17 Oct 2017 16:29:53 -0400	[thread overview]
Message-ID: <DFE86ADF-F143-4284-BBF2-2B04BDBC743C@redhat.com> (raw)
In-Reply-To: <1508264788.11156.11.camel@primarydata.com>

On 17 Oct 2017, at 14:26, Trond Myklebust wrote:
> On Tue, 2017-10-17 at 13:52 -0400, Benjamin Coddington wrote:
>> Ah, yuck.  I read 8.2.2:
>>
>>    When such a set of locks is first created, the server returns a
>>    stateid with seqid value of one.
>>
>> .. and went from there.  Is this a conflict in the spec?
>>
>
> Hmm... I note that the equivalent section 2.2.16 in RFC7530 has been
> changed to remove the bit about the starting value of seqid being
> undefined.
>
> So, if the spec allows us to rely on the seqid always being initialised
> to 1, then we might at least be able to detect that we have to replay
> the open.
> One way to do so might be to keep a count of the number of outstanding
> seqids, and then force OPEN_DOWNGRADE/CLOSE to wait until that number
> hits 0 (or until a state recovery is started).

I can take that approach for another spin, but due to other priorities, I'll
likely not come back to this until next week.  Thanks for your comments.

Ben

      reply	other threads:[~2017-10-17 20:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-17 14:46 [PATCH 0/3] NFSv4.1: OPEN and CLOSE/DOWNGRADE race Benjamin Coddington
2017-10-17 14:46 ` [PATCH 1/3] NFSv4: Move __update_open_stateid() into update_open_stateid() Benjamin Coddington
2017-10-17 14:46 ` [PATCH 2/3] NFSv4: Move nfs_set_open_stateid_locked " Benjamin Coddington
2017-10-17 14:46 ` [PATCH 3/3] NFSv4.1: Detect and retry after OPEN and CLOSE/DOWNGRADE race Benjamin Coddington
2017-10-17 15:49   ` Trond Myklebust
2017-10-17 17:33     ` Benjamin Coddington
2017-10-17 17:42       ` Trond Myklebust
2017-10-17 17:52         ` Benjamin Coddington
2017-10-17 18:26           ` Trond Myklebust
2017-10-17 20:29             ` Benjamin Coddington [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=DFE86ADF-F143-4284-BBF2-2B04BDBC743C@redhat.com \
    --to=bcodding@redhat.com \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@primarydata.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 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.