From: "J. Bruce Fields" <bfields@fieldses.org>
To: 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 v21 1/7] NFSD: add courteous server support for thread with only delegation
Date: Mon, 25 Apr 2022 17:48:50 -0400 [thread overview]
Message-ID: <20220425214850.GK24825@fieldses.org> (raw)
In-Reply-To: <e2b3dfe6-d7c6-3bb1-eebb-0f8cd97c27e7@oracle.com>
On Mon, Apr 25, 2022 at 02:35:27PM -0700, dai.ngo@oracle.com wrote:
> On 4/25/22 1:40 PM, J. Bruce Fields wrote:
> >On Mon, Apr 25, 2022 at 12:42:58PM -0700, dai.ngo@oracle.com wrote:
> >>static inline bool try_to_expire_client(struct nfs4_client *clp)
> >>{
> >> bool ret;
> >>
> >> spin_lock(&clp->cl_cs_lock);
> >> if (clp->cl_state == NFSD4_EXPIRABLE) {
> >> spin_unlock(&clp->cl_cs_lock);
> >> return false; <<<====== was true
> >> }
> >> ret = NFSD4_COURTESY ==
> >> cmpxchg(&clp->cl_state, NFSD4_COURTESY, NFSD4_EXPIRABLE);
> >> spin_unlock(&clp->cl_cs_lock);
> >> return ret;
> >>}
> >So, try_to_expire_client(), as I said, should be just
> >
> > static bool try_to_expire_client(struct nfs4_client *clp)
> > {
> > return COURTESY == cmpxchg(clp->cl_state, COURTESY, EXPIRABLE);
> > }
> >
> >Except, OK, I did forget that somebody else could have already set
> >EXPIRABLE, and we still want to tell the caller to retry in that case,
> >so, oops, let's make it:
> >
> > return ACTIVE != cmpxchg(clp->cl_state, COURTESY, EXPIRABLE);
>
> So functionally this is the same as what i have in the patch, except this
> makes it simpler?
Right.
And my main complaint is still about the code that fails lookups of
EXPIRABLE clients. We shouldn't need to modify find_in_sessionid_hastbl
or other client lookups.
> Do we need to make any change in try_to_activate_client to work with
> this change in try_to_expire_client?
>
> >
> >In other words: set EXPIRABLE if and only if the state is COURTESY, and
> >then tell the caller to retry the operation if and only if the state was
> >previously COURTESY or EXPIRABLE.
> >
> >But we shouldn't need the cl_cs_lock,
>
> The cl_cs_lock is to synchronize between COURTESY client trying to
> reconnect (try_to_activate_client) and another thread is trying to
> resolve a delegation/share/lock conflict (try_to_expire_client).
> So you don't think this is necessary?
Correct, it's not necessary.
The only synchronization is provided by mark_client_expired_locked and
get_client_locked.
We don't need try_to_activate_client. Just set cl_state to ACTIVE in
get_client_locked.
--b.
next prev parent reply other threads:[~2022-04-25 22:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-23 18:44 [PATCH RFC v21 0/7] NFSD: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-04-23 18:44 ` [PATCH RFC v21 1/7] NFSD: add courteous server support for thread with only delegation Dai Ngo
2022-04-25 18:51 ` J. Bruce Fields
2022-04-25 19:42 ` dai.ngo
2022-04-25 20:40 ` J. Bruce Fields
2022-04-25 21:35 ` dai.ngo
2022-04-25 21:48 ` J. Bruce Fields [this message]
2022-04-25 22:24 ` dai.ngo
2022-04-25 23:17 ` J. Bruce Fields
2022-04-23 18:44 ` [PATCH RFC v21 2/7] NFSD: add support for share reservation conflict to courteous server Dai Ngo
2022-04-25 13:15 ` Chuck Lever III
2022-04-25 15:08 ` dai.ngo
2022-04-23 18:44 ` [PATCH RFC v21 3/7] NFSD: move create/destroy of laundry_wq to init_nfsd and exit_nfsd Dai Ngo
2022-04-25 15:27 ` dai.ngo
2022-04-25 19:35 ` J. Bruce Fields
2022-04-25 19:46 ` dai.ngo
2022-04-23 18:44 ` [PATCH RFC v21 4/7] fs/lock: add helper locks_owner_has_blockers to check for blockers Dai Ngo
2022-04-23 18:44 ` [PATCH RFC v21 5/7] fs/lock: add 2 callbacks to lock_manager_operations to resolve conflict Dai Ngo
2022-04-23 18:44 ` [PATCH RFC v21 6/7] NFSD: add support for lock conflict to courteous server Dai Ngo
2022-04-23 18:44 ` [PATCH RFC v21 7/7] NFSD: Show state of courtesy client in client info Dai Ngo
2022-04-25 16:17 ` [PATCH RFC v21 0/7] NFSD: Initial implementation of NFSv4 Courteous Server J. Bruce Fields
2022-04-25 17:53 ` J. Bruce Fields
2022-04-25 18:16 ` dai.ngo
2022-04-25 19:19 ` 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=20220425214850.GK24825@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox