All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Fields <bfields@fieldses.org>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"Adamson, Dros" <Weston.Adamson@netapp.com>,
	Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 2/3] NFS: Ensure that we free the rpc_task after read and write cleanups are done
Date: Fri, 4 Jan 2013 14:12:55 -0500	[thread overview]
Message-ID: <20130104191255.GA13828@fieldses.org> (raw)
In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA91198C253@SACEXCMBX04-PRD.hq.netapp.com>

On Fri, Jan 04, 2013 at 06:52:12PM +0000, Myklebust, Trond wrote:
> On Fri, 2013-01-04 at 13:29 -0500, Bruce Fields wrote:
> > On Fri, Jan 04, 2013 at 01:15:01PM -0500, Trond Myklebust wrote:
> > > This patch ensures that we free the rpc_task after the cleanup callbacks
> > > are done in order to avoid a deadlock problem that can be triggered if
> > > the callback needs to wait for another workqueue item to complete.
> > 
> > Makes sense to me!
> > 
> > (Dumb question: so read and write data are the only two cases where the
> > calldata embeds an rpc task?  Why is that?)
> 
> nfs_commit_data and nfs_layoutcommit_data do too. The idea is to improve
> reliability when writing back dirty data in low memory conditions. The
> struct nfs_write_data and nfs_commit_data have their own mempool in
> order to guarantee a minimum number of available slots. By embedding the
> rpc_task, we can extend that guarantee to cover (part of) the RPC call
> too.
> 
> The only reason why nfs_read_data has the same embedding is for symmetry
> with nfs_write_data.

OK, thanks for the explanation.

--b.

  reply	other threads:[~2013-01-04 19:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 15:33 nfsd oops on Linus' current tree Dave Jones
2012-12-21 18:08 ` J. Bruce Fields
2012-12-21 18:40   ` Myklebust, Trond
2012-12-21 23:08     ` J. Bruce Fields
2012-12-21 23:15       ` Myklebust, Trond
2012-12-21 23:26         ` J. Bruce Fields
2012-12-21 23:36           ` Myklebust, Trond
2012-12-21 23:45             ` J. Bruce Fields
2013-01-03 16:28               ` Adamson, Dros
2013-01-03 20:11                 ` J. Bruce Fields
2013-01-03 20:27                   ` Adamson, Dros
2013-01-03 20:52                     ` J. Bruce Fields
2013-01-03 22:15                       ` Tejun Heo
2013-01-03 22:08                   ` Tejun Heo
2013-01-03 22:12                     ` Myklebust, Trond
2013-01-03 22:26                       ` Tejun Heo
2013-01-03 22:34                         ` Tejun Heo
2013-01-03 23:11                         ` Myklebust, Trond
     [not found]                         ` <1357254692.55285.33.camel@lade.trondhjem.org>
2013-01-03 23:26                           ` Myklebust, Trond
2013-01-04 17:11                             ` Adamson, Dros
2013-01-04 18:15                               ` [PATCH 1/3] SUNRPC: Ensure that we free the rpc_task after cleanups are done Trond Myklebust
2013-01-04 18:15                                 ` [PATCH 2/3] NFS: Ensure that we free the rpc_task after read and write " Trond Myklebust
2013-01-04 18:15                                   ` [PATCH 3/3] SUNRPC: Partial revert of commit 168e4b39d1afb79a7e3ea6c3bb246b4c82c6bdb9 Trond Myklebust
2013-01-04 18:29                                   ` [PATCH 2/3] NFS: Ensure that we free the rpc_task after read and write cleanups are done Bruce Fields
2013-01-04 18:52                                     ` Myklebust, Trond
2013-01-04 19:12                                       ` Bruce Fields [this message]
2013-01-07 17:47                                 ` [PATCH 1/3] SUNRPC: Ensure that we free the rpc_task after " Tejun Heo
2013-01-07 17:54                                   ` Myklebust, Trond
2013-01-03 22:03                 ` nfsd oops on Linus' current tree Tejun Heo
2013-01-03 23:08                   ` J. Bruce Fields
2012-12-22  0:48   ` [PATCH] Revert "nfsd: warn on odd reply state in nfsd_vfs_read" J. Bruce Fields

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=20130104191255.GA13828@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=Weston.Adamson@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tj@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.