All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: bfields@fieldses.org, Christoph Hellwig <hch@lst.de>,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH RFC] nfsd: serialize layout stateid morphing operations
Date: Sun, 11 Oct 2015 15:15:27 +0200	[thread overview]
Message-ID: <20151011131527.GA4007@lst.de> (raw)
In-Reply-To: <1442491104-30080-1-git-send-email-jeff.layton@primarydata.com>

On Thu, Sep 17, 2015 at 07:58:24AM -0400, Jeff Layton wrote:
> In order to allow the client to make a sane determination of what
> happened with racing LAYOUTGET/LAYOUTRETURN/CB_LAYOUTRECALL calls, we
> must ensure that the seqids return accurately represent the order of
> operations. The simplest way to do that is to ensure that operations on
> a single stateid are serialized.
> 
> This patch adds a mutex to the layout stateid, and locks it when
> checking the layout stateid's seqid. The mutex is held over the entire
> operation and released after the seqid is bumped.
> 
> Note that in the case of CB_LAYOUTRECALL we must move the increment of
> the seqid and setting into a new cb "prepare" operation. The lease
> infrastructure will call the lm_break callback with a spinlock held, so
> and we can't take the mutex in that codepath.

I can't say I like the long running mutex all that much.  What kinds
of reproducers do you have where the current behavior causes problems?

  reply	other threads:[~2015-10-11 13:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-17 11:58 [PATCH RFC] nfsd: serialize layout stateid morphing operations Jeff Layton
2015-10-11 13:15 ` Christoph Hellwig [this message]
2015-10-11 20:51   ` Jeff Layton
2015-10-23 19:35     ` J. Bruce Fields
2015-11-29  4:07 ` Kinglong Mee
2015-11-29 13:46   ` Jeff Layton
2015-11-30  2:57     ` Kinglong Mee
2015-11-30 21:34       ` J. Bruce Fields
2015-12-01  0:33         ` Jeff Layton
2015-12-01  0:55           ` Trond Myklebust
2015-12-01 11:56           ` Christoph Hellwig
2015-12-01 22:48             ` Jeff Layton
2015-12-02  7:25               ` Christoph Hellwig
2015-12-03 22:08                 ` J. Bruce Fields
2015-12-04  8:38                   ` Christoph Hellwig
2015-12-04 20:51                     ` Jeff Layton
2015-12-05 12:02                       ` Christoph Hellwig
2015-12-05 12:24                         ` Jeff Layton
2015-12-06 13:09                           ` Jeff Layton
2015-12-07 13:09                             ` Christoph Hellwig
2015-12-07 13:28                               ` Jeff Layton
2015-12-07 14:17                                 ` Christoph Hellwig
2015-12-07 16:12                                   ` Jeff Layton
2015-12-07 16:43                                     ` J. Bruce Fields
2015-12-16 16:55                             ` J. Bruce Fields
2015-12-07 13:07                           ` Christoph Hellwig

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=20151011131527.GA4007@lst.de \
    --to=hch@lst.de \
    --cc=bfields@fieldses.org \
    --cc=jlayton@poochiereds.net \
    --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.