From: Chuck Lever <chuck.lever@oracle.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 08/15] SUNRPC: Ensure rpcauth_prune_expired() respects the nr_to_scan parameter
Date: Fri, 14 May 2010 15:18:59 -0400 [thread overview]
Message-ID: <4BEDA223.9080701@oracle.com> (raw)
In-Reply-To: <1273862242.4732.39.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 05/14/10 02:37 PM, Trond Myklebust wrote:
> On Fri, 2010-05-14 at 14:07 -0400, Trond Myklebust wrote:
>> On Fri, 2010-05-14 at 13:32 -0400, Chuck Lever wrote:
>>> When mm calls with nr_to_scan set to zero, it doesn't expect a -1
>>> return, it just uses the returned value. mm checks for a -1 return only
>>> when a non-zero scan count argument is passed.
>>>
>>> So the check you added here (and in the access cache shrinker) to return
>>> -1 when the gfp_mask doesn't contain GFP_KERNEL could cause some
>>> trouble. It would be safer if we return -1 _after_ checking for
>>> nr_to_scan == 0.
>>
>> Oh... You're referring to the change that was added in Patch 6/15
>> SUNRPC: Dont run rpcauth_cache_shrinker() when gfp_mask is GFP_NOFS? I
>> got confused...
Sorry.
>> I can perhaps rather add a check for nr_to_scan != 0 in that patch...
>
> OK... How about the following? (and ditto for the access cache shrinker)
A comment that explains the choice of return codes might be nice, but
yeah, I guess that will work. It avoids the need to take the
rpc_credcache_lock in cases where you can't do any shrinkage anyway.
So, for the series:
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Looked at patch 2 and 3, but my understanding of gss and v4 reclaim
isn't terribly extensive. I didn't see anything egregious in those two,
but I can't really comment intelligently on the high-level logic changes.
> --------------------------------------------------------------------------------------------
>> From 8048209c54b95046a23cd994b3d0520757ea5845 Mon Sep 17 00:00:00 2001
> From: Trond Myklebust<Trond.Myklebust@netapp.com>
> Date: Thu, 13 May 2010 12:51:03 -0400
> Subject: [PATCH 06/15] 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>
> ---
> net/sunrpc/auth.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
> index 95afe79..0667a36 100644
> --- a/net/sunrpc/auth.c
> +++ b/net/sunrpc/auth.c
> @@ -270,6 +270,8 @@ rpcauth_cache_shrinker(int nr_to_scan, gfp_t gfp_mask)
> LIST_HEAD(free);
> int res;
>
> + if ((gfp_mask& GFP_KERNEL) != GFP_KERNEL)
> + return (nr_to_scan == 0) ? 0 : -1;
> if (list_empty(&cred_unused))
> return 0;
> spin_lock(&rpc_credcache_lock);
prev parent reply other threads:[~2010-05-14 19:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-13 21:08 [PATCH 01/15] SUNRPC: Fix xs_setup_bc_tcp() Trond Myklebust
2010-05-13 21:08 ` [PATCH 02/15] NFSv4: Don't use GFP_KERNEL allocations in state recovery Trond Myklebust
2010-05-13 21:08 ` [PATCH 03/15] NFS: Don't use GFP_KERNEL in rpcsec_gss downcalls Trond Myklebust
2010-05-13 21:08 ` [PATCH 04/15] NFS: Clean up nfs_create_request() Trond Myklebust
2010-05-13 21:08 ` [PATCH 05/15] NFS: Read requests can use GFP_KERNEL Trond Myklebust
2010-05-13 21:08 ` [PATCH 06/15] SUNRPC: Dont run rpcauth_cache_shrinker() when gfp_mask is GFP_NOFS Trond Myklebust
2010-05-13 21:08 ` [PATCH 07/15] SUNRPC: Ensure memory shrinker doesn't waste time in rpcauth_prune_expired() Trond Myklebust
2010-05-13 21:08 ` [PATCH 08/15] SUNRPC: Ensure rpcauth_prune_expired() respects the nr_to_scan parameter Trond Myklebust
2010-05-13 21:08 ` [PATCH 09/15] NFS: Don't run nfs_access_cache_shrinker() when the mask is GFP_NOFS Trond Myklebust
2010-05-13 21:08 ` [PATCH 10/15] NFS: Clean up nfs_access_zap_cache() Trond Myklebust
2010-05-13 21:08 ` [PATCH 11/15] NFS: Don't call iput() in nfs_access_cache_shrinker Trond Myklebust
2010-05-13 21:08 ` [PATCH 12/15] SUNRPC: Move the task->tk_bytes_sent and tk_rtt to struct rpc_rqst Trond Myklebust
2010-05-13 21:08 ` [PATCH 13/15] SUNRPC: Remove the 'tk_magic' debugging field Trond Myklebust
2010-05-13 21:08 ` [PATCH 14/15] SUNRPC: Reorder the struct rpc_task fields Trond Myklebust
2010-05-13 21:08 ` [PATCH 15/15] SUNRPC: Don't spam gssd with upcall requests when the kerberos key expired Trond Myklebust
2010-05-14 16:34 ` [PATCH 08/15] SUNRPC: Ensure rpcauth_prune_expired() respects the nr_to_scan parameter Chuck Lever
2010-05-14 17:13 ` Trond Myklebust
[not found] ` <1273857200.4732.2.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-05-14 17:32 ` Chuck Lever
2010-05-14 18:07 ` Trond Myklebust
[not found] ` <1273860432.4732.30.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-05-14 18:37 ` Trond Myklebust
[not found] ` <1273862242.4732.39.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2010-05-14 19:18 ` Chuck Lever [this message]
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=4BEDA223.9080701@oracle.com \
--to=chuck.lever@oracle.com \
--cc=Trond.Myklebust@netapp.com \
--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.