Hi Trond, On Mon, May 17, 2010 at 06:28:01PM -0400, Trond Myklebust wrote: > commit 9c7e7e23371e629dbb3b341610a418cdf1c19d91 > Author: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > 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@xxxxxxxxxx> > > commit 1a81bb8a1fa62ccb9b2411ac10ce702ca4ed302a > Author: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > Date: Thu May 13 12:51:06 2010 -0400 > > NFS: Clean up nfs_access_zap_cache() > > Signed-off-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > > commit 61d5eb2985b3b1d69fd53d7dc9789037c27f8d91 > Author: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > 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@xxxxxxxxxx> > > commit 93a05e65c090dda9cbd79d0cf57b65c4dbd8da55 > Author: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > 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@xxxxxxxxxx> > > commit d300a41ef1c39cc5e6b90fd8834ea7ab16b5c48f > Author: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > 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@xxxxxxxxxx> > > commit 93870d76fee22e887aa6e7e1fc904dbeca976928 > Author: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > 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@xxxxxxxxxx> > > commit 1f4c86c0be9064ab4eebd9e67c84606c1cfeec4b > Author: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > 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@xxxxxxxxxx> > > commit 8535b2be5181fc3019e4150567ef53210fe3b04f > Author: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > 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@xxxxxxxxxx> 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-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
