All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benjamin Coddington" <bcodding@redhat.com>
To: "List Linux NFS Mailing" <linux-nfs@vger.kernel.org>
Subject: CLOSE/OPEN race
Date: Sat, 12 Nov 2016 06:08:50 -0500	[thread overview]
Message-ID: <9E2B8A0D-7B0E-4AE5-800A-0EF3F7F7F694@redhat.com> (raw)

I've been seeing the following on a modified version of generic/089
that gets the client stuck sending LOCK with NFS4ERR_OLD_STATEID.

1. Client has open stateid A, sends a CLOSE
2. Client sends OPEN with same owner
3. Client sends another OPEN with same owner
4. Client gets a reply to OPEN in 3, stateid is B.2 (stateid B sequence 2)
5. Client does LOCK,LOCKU,FREE_STATEID from B.2
6. Client gets a reply to CLOSE in 1
7. Client gets reply to OPEN in 2, stateid is B.1
8. Client sends LOCK with B.1 - OLD_STATEID, now stuck in a loop

The CLOSE response in 6 causes us to clear NFS_OPEN_STATE, so that the OPEN
response in 7 is able to update the open_stateid even though it has a lower
sequence number.

I think this case could be handled by never updating the open_stateid if the
stateids match but the sequence number of the new state is less than the
current open_state.

Any thoughts?

Ben

             reply	other threads:[~2016-11-12 11:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-12 11:08 Benjamin Coddington [this message]
2016-11-12 12:54 ` CLOSE/OPEN race Jeff Layton
2016-11-12 15:31   ` Benjamin Coddington
2016-11-12 16:52     ` Jeff Layton
2016-11-12 18:03       ` Benjamin Coddington
2016-11-12 21:16         ` Jeff Layton
2016-11-13  2:56           ` Jeff Layton
2016-11-13 13:34             ` Benjamin Coddington
2016-11-13 14:22               ` Benjamin Coddington
2016-11-13 14:33               ` Jeff Layton
2016-11-13 14:47             ` Trond Myklebust
2016-11-14 14:53               ` Benjamin Coddington
2016-11-14 16:29                 ` Trond Myklebust
2016-11-14 18:40                   ` Benjamin Coddington
2016-11-12 18:16 ` Trond Myklebust
2016-11-12 18:46   ` Benjamin Coddington
2016-11-13  3:09   ` Jeff Layton

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=9E2B8A0D-7B0E-4AE5-800A-0EF3F7F7F694@redhat.com \
    --to=bcodding@redhat.com \
    --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.