From: "J. Bruce Fields" <bfields@fieldses.org>
To: Dai Ngo <dai.ngo@oracle.com>
Cc: chuck.lever@oracle.com, jlayton@redhat.com,
viro@zeniv.linux.org.uk, linux-nfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC v9 2/2] nfsd: Initial implementation of NFSv4 Courteous Server
Date: Wed, 12 Jan 2022 14:40:54 -0500 [thread overview]
Message-ID: <20220112194054.GD10518@fieldses.org> (raw)
In-Reply-To: <1641840653-23059-3-git-send-email-dai.ngo@oracle.com>
On Mon, Jan 10, 2022 at 10:50:53AM -0800, Dai Ngo wrote:
> static time64_t
> nfs4_laundromat(struct nfsd_net *nn)
> {
> @@ -5587,7 +5834,9 @@ nfs4_laundromat(struct nfsd_net *nn)
> };
> struct nfs4_cpntf_state *cps;
> copy_stateid_t *cps_t;
> + struct nfs4_stid *stid;
> int i;
> + int id;
>
> if (clients_still_reclaiming(nn)) {
> lt.new_timeo = 0;
> @@ -5608,8 +5857,41 @@ nfs4_laundromat(struct nfsd_net *nn)
> spin_lock(&nn->client_lock);
> list_for_each_safe(pos, next, &nn->client_lru) {
> clp = list_entry(pos, struct nfs4_client, cl_lru);
> - if (!state_expired(<, clp->cl_time))
> + spin_lock(&clp->cl_cs_lock);
> + if (test_bit(NFSD4_DESTROY_COURTESY_CLIENT, &clp->cl_flags))
> + goto exp_client;
> + if (test_bit(NFSD4_COURTESY_CLIENT, &clp->cl_flags)) {
> + if (ktime_get_boottime_seconds() >= clp->courtesy_client_expiry)
> + goto exp_client;
> + /*
> + * after umount, v4.0 client is still around
> + * waiting to be expired. Check again and if
> + * it has no state then expire it.
> + */
> + if (clp->cl_minorversion) {
> + spin_unlock(&clp->cl_cs_lock);
> + continue;
> + }
I'm not following that comment or that logic.
> + }
> + if (!state_expired(<, clp->cl_time)) {
> + spin_unlock(&clp->cl_cs_lock);
> break;
> + }
> + id = 0;
> + spin_lock(&clp->cl_lock);
> + stid = idr_get_next(&clp->cl_stateids, &id);
> + if (stid && !nfs4_anylock_conflict(clp)) {
> + /* client still has states */
I'm a little confused by that comment. I think what you just checked is
that the client has some state, *and* nobody is waiting for one of its
locks. For me, that comment just conufses things.
> + spin_unlock(&clp->cl_lock);
Is nn->client_lock enough to guarantee that the condition you just
checked still holds? (Honest question, I'm not sure.)
> + clp->courtesy_client_expiry =
> + ktime_get_boottime_seconds() + courtesy_client_expiry;
> + set_bit(NFSD4_COURTESY_CLIENT, &clp->cl_flags);
> + spin_unlock(&clp->cl_cs_lock);
> + continue;
> + }
> + spin_unlock(&clp->cl_lock);
> +exp_client:
> + spin_unlock(&clp->cl_cs_lock);
> if (mark_client_expired_locked(clp))
> continue;
> list_add(&clp->cl_lru, &reaplist);
In general this loop is more complicated than the rest of the logic in
nfs4_laundromat(). I'd be looking for ways to simplify it and/or move some
of it into a helper function.
--b.
> @@ -5689,9 +5971,6 @@ nfs4_laundromat(struct nfsd_net *nn)
> return max_t(time64_t, lt.new_timeo, NFSD_LAUNDROMAT_MINTIMEOUT);
> }
next prev parent reply other threads:[~2022-01-12 19:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 18:50 [PATCH RFC v9 0/2] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-01-10 18:50 ` [PATCH RFC v9 1/2] fs/lock: add new callback, lm_expire_lock, to lock_manager_operations Dai Ngo
2022-01-10 18:50 ` [PATCH RFC v9 2/2] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-01-10 20:52 ` kernel test robot
2022-01-10 23:17 ` Chuck Lever III
2022-01-11 1:03 ` dai.ngo
2022-01-11 15:49 ` Chuck Lever III
2022-01-12 18:53 ` Bruce Fields
2022-01-12 18:56 ` dai.ngo
2022-01-12 19:40 ` J. Bruce Fields [this message]
2022-01-13 8:51 ` dai.ngo
2022-01-13 15:42 ` J. Bruce Fields
2022-01-13 19:51 ` dai.ngo
2022-01-12 19:52 ` J. Bruce Fields
2022-01-10 19:03 ` [PATCH RFC v9 0/2] " Chuck Lever III
2022-01-12 18:59 ` J. Bruce Fields
2022-01-12 19:05 ` dai.ngo
2022-01-12 19:21 ` J. Bruce Fields
2022-01-12 19:31 ` dai.ngo
2022-01-12 19:42 ` J. Bruce Fields
2022-01-12 20:34 ` dai.ngo
2022-01-12 20:39 ` J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2022-01-10 18:40 Dai Ngo
2022-01-10 18:40 ` [PATCH RFC v9 2/2] " Dai Ngo
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=20220112194054.GD10518@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.