From: Benny Halevy <bhalevy@panasas.com>
To: "J. Bruce Fields" <bfields@citi.umich.edu>
Cc: NFS list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/8] nfsd4: keep the client from expiring while in use by nfs41 compounds
Date: Mon, 10 May 2010 17:15:43 +0300 [thread overview]
Message-ID: <4BE8150F.2050706@panasas.com> (raw)
In-Reply-To: <20100509165551.GA15429@fieldses.org>
On May. 09, 2010, 19:55 +0300, "J. Bruce Fields" <bfields@citi.umich.edu> wrote:
> On Sun, May 09, 2010 at 09:30:31AM +0300, Benny Halevy wrote:
>> Correct. The intentions are:
>> 1. Make the laundromat process ignore clients that are in
>> use by a 4.1 session.
>> 2. Renew the client when the compound ends, rather than when it begins.
>> 3. Unhash the client when it's expired explicitly but don't destroy it
>> until there's no reference to it.
>
> OK. My one slight worry there is to make sure that code getting a
> pointer to a client through a sessionid won't inadvertently assume it's
> still hashed.
That's a good point.
In fact, the client should not be renewed when the compound is done
if it was already explicitly expired.
Another way to deal with this which may be safer but is less optimal
is to keep only the sessionid and look it up on each use. Then, using
it while holding the state lock will make sure it's valid when used.
Benny
>
> By the way, the current stateid may present a similar problem to the
> session, since it also lasts across compound ops and references a
> client (and other state).
>
> Looking through the code.... We don't implement the current stateid at
> all yet. Ouch.
>
> I'll add that to the wiki.
>
>>>> [PATCH 8/8] nfsd41: cstate->session can NULL in nfsd4_destroy_session
>>>> I think this was introduced in: 26c0c75 nfsd4: fix unlikely race in session replay case
>>>> though I'm not sure how it ever worked correctly...
>>> Me neither. I've got a similar patch in my tree.
>> Heh, I see.
>> 5d4cec2 nfsd4: fix bare destroy_session null dereference
>
> Apologies, I'd applied it privately but not pushed it out yet.... I
> should have gotten that out faster.
>
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-05-10 14:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 22:37 [PATCH 0/8] nfsd4: keep the client from expiring while in use by nfs41 compounds Benny Halevy
2010-05-04 22:43 ` [PATCH 1/8] nfsd4: rename sessionid_lock to client_lock Benny Halevy
2010-05-04 22:43 ` [PATCH 2/8] nfsd4: fold release_session into expire_client Benny Halevy
2010-05-04 22:44 ` [PATCH 3/8] nfsd4: use list_move in move_to_confirmed Benny Halevy
2010-05-04 22:44 ` [PATCH 4/8] nfsd4: extend the client_lock to cover cl_lru Benny Halevy
2010-05-07 22:29 ` J. Bruce Fields
2010-05-09 6:18 ` Benny Halevy
2010-05-04 22:44 ` [PATCH 5/8] nfsd4: refactor expire_client Benny Halevy
2010-05-04 22:44 ` [PATCH 6/8] nfsd4: introduce nfs4_client.cl_refcount Benny Halevy
2010-05-04 22:44 ` [PATCH 7/8] nfsd4: keep a reference count on client while in use Benny Halevy
2010-05-04 22:45 ` [PATCH 8/8] nfsd41: cstate->session can NULL in nfsd4_destroy_session Benny Halevy
2010-05-07 22:38 ` [PATCH 0/8] nfsd4: keep the client from expiring while in use by nfs41 compounds J. Bruce Fields
2010-05-09 6:30 ` Benny Halevy
2010-05-09 16:55 ` J. Bruce Fields
2010-05-10 14:15 ` Benny Halevy [this message]
2010-05-10 19:01 ` J. Bruce Fields
2010-05-11 7:27 ` Benny Halevy
2010-05-11 14:39 ` J. Bruce Fields
2010-05-11 16:05 ` J. Bruce Fields
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=4BE8150F.2050706@panasas.com \
--to=bhalevy@panasas.com \
--cc=bfields@citi.umich.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox