All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@citi.umich.edu>
To: Benny Halevy <bhalevy@panasas.com>
Cc: linux-nfs@vger.kernel.org, pnfs@linux-nfs.org
Subject: Re: [RFC 04/11] nfsd: mark client for renew
Date: Wed, 16 Dec 2009 17:06:00 -0500	[thread overview]
Message-ID: <20091216220600.GG28822@fieldses.org> (raw)
In-Reply-To: <4B295775.1000301@panasas.com>

On Wed, Dec 16, 2009 at 11:56:05PM +0200, Benny Halevy wrote:
> On Dec. 16, 2009, 22:53 +0200, " J. Bruce Fields" <bfields@citi.umich.edu> wrote:
> > On Wed, Dec 16, 2009 at 03:48:39PM -0500,  J. Bruce Fields wrote:
> >> On Wed, Dec 16, 2009 at 07:41:12PM +0200, Benny Halevy wrote:
> >>> Mark the nfs4_client for renew on operations holding a stateid (or nfs41
> >>> OP_SEQUENCE).
> >>> Do the actual lru list update when the compound processing is complete.
> >>> This will prevents the client from being expired by the laundromat while
> >>> the compound is in progress.
> >>>
> >>> Signed-off-by: Benny Halevy <bhalevy@panasas.com>
> >>> ---
> >>>  fs/nfsd/nfs4proc.c  |    5 +++++
> >>>  fs/nfsd/nfs4state.c |   39 +++++++++++++++++++++++++++++++++++----
> >>>  fs/nfsd/state.h     |    1 +
> >>>  fs/nfsd/xdr4.h      |    1 +
> >>>  4 files changed, 42 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> >>> index 37514c4..a8e9731 100644
> >>> --- a/fs/nfsd/nfs4proc.c
> >>> +++ b/fs/nfsd/nfs4proc.c
> >>> @@ -1010,6 +1010,7 @@ nfsd4_proc_compound(struct svc_rqst *rqstp,
> >>>  	resp->opcnt = 0;
> >>>  	resp->rqstp = rqstp;
> >>>  	resp->cstate.minorversion = args->minorversion;
> >>> +	resp->cstate.renew_client = NULL;
> >>>  	resp->cstate.replay_owner = NULL;
> >>>  	fh_init(&resp->cstate.current_fh, NFS4_FHSIZE);
> >>>  	fh_init(&resp->cstate.save_fh, NFS4_FHSIZE);
> >>> @@ -1114,6 +1115,10 @@ encode_op:
> >>>  	fh_put(&resp->cstate.current_fh);
> >>>  	fh_put(&resp->cstate.save_fh);
> >>>  	BUG_ON(resp->cstate.replay_owner);
> >>> +	if (resp->cstate.renew_client) {
> >>> +		renew_client(resp->cstate.renew_client);
> >>> +		put_nfs4_client(resp->cstate.renew_client);
> >>> +	}
> >>>  out:
> >>>  	nfsd4_release_compoundargs(args);
> >>>  	/* Reset deferral mechanism for RPC deferrals */
> >>> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> >>> index c456551..16ccab3 100644
> >>> --- a/fs/nfsd/nfs4state.c
> >>> +++ b/fs/nfsd/nfs4state.c
> >>> @@ -634,8 +634,39 @@ free_session(struct kref *kref)
> >>>  }
> >>>  
> >>>  static inline void
> >>> +mark_client_for_renew(struct nfsd4_compound_state *cstate,
> >>> +		      struct nfs4_client *clp)
> >>> +{
> >>> +	int old_state = atomic_cmpxchg(&clp->cl_state, CL_STATE_NORMAL,
> >>> +				       CL_STATE_RENEW);
> >>> +
> >>> +	if (old_state != CL_STATE_EXPIRED) {
> >>> +		cstate->renew_client = clp;
> >>> +		get_nfs4_client(clp);
> >> If cstate->renew_client is already set, then we may leak a reference
> >> count here, right?
> >>
> >> Also: at least in the v4 case, I don't think there's anything preventing
> >> cstate->renew_client being already set to a different client.  (With
> >> sessions hopefully that's not possible.)
> >>
> 
> Yeah.  That's a valid point.  So if it is already set then
> if it is the same client we can do nothing, else we can renew
> the previous one here put it and replace cstate->renew_client.

I'm not sure if that can only happen if someone's intentionally messing
with us, or if maybe there's a legitimate case where it can happen
(maybe when a new client is created by some op in the compound?) But,
yes, that sounds like a safe way to handle it.

--b.

  reply	other threads:[~2009-12-16 22:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-16 17:39 [RFC 0/11] state lock reduction prep Benny Halevy
2009-12-16 17:40 ` [RFC 01/11] nfsd: introduce nfs4_client state Benny Halevy
2009-12-16 22:33   ` [pnfs] " Peter Staubach
2009-12-16 23:17     ` Benny Halevy
2009-12-16 17:40 ` [RFC 02/11] nfsd: mark client state as expired in expire_client Benny Halevy
2009-12-16 17:40 ` [RFC 03/11] nfsd: introduce get_nfs4_client Benny Halevy
2009-12-16 17:41 ` [RFC 04/11] nfsd: mark client for renew Benny Halevy
2009-12-16 20:48   `  J. Bruce Fields
2009-12-16 20:53     `  J. Bruce Fields
2009-12-16 21:56       ` Benny Halevy
2009-12-16 22:06         ` J. Bruce Fields [this message]
2009-12-16 22:23           ` Benny Halevy
2009-12-17 20:19             ` J. Bruce Fields
2009-12-16 17:41 ` [RFC 05/11] nfsd: skip clients marked for renewal Benny Halevy
2009-12-16 20:58   `  J. Bruce Fields
2009-12-16 21:54     ` Benny Halevy
2009-12-16 17:41 ` [RFC 06/11] nfsd41: no need to hold the state lock around mark_client_for_renew Benny Halevy
2009-12-16 17:41 ` [RFC 07/11] nfsd: rename recall_lock to deleg_lock Benny Halevy
2009-12-16 17:42 ` [RFC 08/11] nfsd: use deleg_lock to protect dl_perfile and dl_perclnt Benny Halevy
2009-12-16 17:42 ` [RFC 09/11] nfsd: get a reference count on the delgation while outside of the deleg_lock Benny Halevy
2009-12-16 17:42 ` [RFC 10/11] nfsd: close delegation only on last reference Benny Halevy
2009-12-16 21:18   `  J. Bruce Fields
2009-12-16 22:04     ` Benny Halevy
2009-12-16 17:42 ` [RFC 11/11] nfsd: refactor unhash_delegation Benny Halevy

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=20091216220600.GG28822@fieldses.org \
    --to=bfields@citi.umich.edu \
    --cc=bhalevy@panasas.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=pnfs@linux-nfs.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.