From: Lukas Hejtmanek <xhejtman@ics.muni.cz>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [GIT PULL] Please pull NFS client changes
Date: Tue, 18 May 2010 10:59:17 +0200 [thread overview]
Message-ID: <20100518085917.GH14172@ics.muni.cz> (raw)
In-Reply-To: <1274135281.18654.2.camel@heimdal.trondhjem.org>
Hi Trond,
On Mon, May 17, 2010 at 06:28:01PM -0400, Trond Myklebust wrote:
> commit 9c7e7e23371e629dbb3b341610a418cdf1c19d91
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu May 13 12:51:06 2010 -0400
>
> NFS: Don't call iput() in nfs_access_cache_shrinker
>
> iput() can potentially attempt to allocate memory, so we should avoid
> calling it in a memory shrinker. Instead, rely on the fact that iput() will
> call nfs_access_zap_cache().
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> commit 1a81bb8a1fa62ccb9b2411ac10ce702ca4ed302a
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu May 13 12:51:06 2010 -0400
>
> NFS: Clean up nfs_access_zap_cache()
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> commit 61d5eb2985b3b1d69fd53d7dc9789037c27f8d91
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu May 13 12:51:06 2010 -0400
>
> NFS: Don't run nfs_access_cache_shrinker() when the mask is GFP_NOFS
>
> Both iput() and put_rpccred() might allocate memory under certain
> circumstances, so make sure that we don't recurse and deadlock...
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> commit 93a05e65c090dda9cbd79d0cf57b65c4dbd8da55
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu May 13 12:51:06 2010 -0400
>
> SUNRPC: Ensure memory shrinker doesn't waste time in rpcauth_prune_expired()
>
> The 'cred_unused' list, that is traversed by rpcauth_cache_shrinker is
> ordered by time. If we hit a credential that is under the 60 second garbage
> collection moratorium, we should exit because we know at that point that
> all successive credentials are subject to the same moratorium...
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> commit d300a41ef1c39cc5e6b90fd8834ea7ab16b5c48f
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu May 13 12:51:03 2010 -0400
>
> SUNRPC: Dont run rpcauth_cache_shrinker() when gfp_mask is GFP_NOFS
>
> Under some circumstances, put_rpccred() can end up allocating memory, so
> check the gfp_mask to prevent deadlocks.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> commit 93870d76fee22e887aa6e7e1fc904dbeca976928
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu May 13 12:51:03 2010 -0400
>
> NFS: Read requests can use GFP_KERNEL.
>
> There is no danger of deadlock should the allocation trigger page
> writeback.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> commit 1f4c86c0be9064ab4eebd9e67c84606c1cfeec4b
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu May 13 12:51:02 2010 -0400
>
> NFS: Don't use GFP_KERNEL in rpcsec_gss downcalls
>
> Again, we can deadlock if the memory reclaim triggers a writeback that
> requires a rpcsec_gss credential lookup.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> commit 8535b2be5181fc3019e4150567ef53210fe3b04f
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu May 13 12:51:01 2010 -0400
>
> NFSv4: Don't use GFP_KERNEL allocations in state recovery
>
> We do not want to have the state recovery thread kick off and wait for a
> memory reclaim, since that may deadlock when the writebacks end up
> waiting for the state recovery thread to complete.
>
> The safe thing is therefore to use GFP_NOFS in all open, close,
> delegation return, lock, etc. operations that may be called by the
> state recovery thread.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
do these solve also cases when rpc.gssd itself needs memory and there is no
free memory because there is a lot of dirty pages as NFS cache?
rpc.gssd needs memory whenever it needs to create a new kerberos context (in
particular, fread needs it).
--
Lukáš Hejtmánek
next prev parent reply other threads:[~2010-05-18 8:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-17 22:28 [GIT PULL] Please pull NFS client changes Trond Myklebust
2010-05-18 8:59 ` Lukas Hejtmanek [this message]
2010-08-06 18:26 Trond Myklebust
2011-01-11 23:08 Trond Myklebust
2011-03-17 17:19 Trond Myklebust
2011-07-27 18:40 [GIT PULL] Please pull nfs " Trond Myklebust
2011-10-25 12:25 [GIT PULL] Please pull NFS " Trond Myklebust
2014-01-27 16:49 Trond Myklebust
2014-07-19 20:07 Trond Myklebust
2014-10-06 13:03 Trond Myklebust
2014-12-08 3:09 Trond Myklebust
2015-09-07 20:59 Trond Myklebust
2015-09-08 1:59 ` Stephen Rothwell
2015-09-08 6:01 ` Christoph Hellwig
2015-09-11 16:27 ` Christoph Hellwig
2015-09-11 17:06 ` Trond Myklebust
2016-01-14 21:09 Trond Myklebust
2017-10-09 17:35 Trond Myklebust
2018-01-30 14:39 Trond Myklebust
2018-11-25 3:04 Trond Myklebust
2018-11-25 17:45 ` pr-tracker-bot
2018-12-06 21:55 Trond Myklebust
2018-12-07 18:35 ` pr-tracker-bot
2022-04-08 17:30 Trond Myklebust
2022-04-08 17:46 ` pr-tracker-bot
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=20100518085917.GH14172@ics.muni.cz \
--to=xhejtman@ics.muni.cz \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=torvalds@linux-foundation.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 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).