lkml.org 
[lkml]   [2010]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Please pull NFS client changes
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-05-18 11:01    [W:0.116 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site