linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: dai.ngo@oracle.com
To: "J. Bruce Fields" <bfields@fieldses.org>
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: Thu, 13 Jan 2022 11:51:43 -0800	[thread overview]
Message-ID: <f4c9b6fa-ef75-55b0-53dc-4830d6aef94e@oracle.com> (raw)
In-Reply-To: <20220113154206.GA32679@fieldses.org>


On 1/13/22 7:42 AM, J. Bruce Fields wrote:
> On Thu, Jan 13, 2022 at 12:51:57AM -0800, dai.ngo@oracle.com wrote:
>> On 1/12/22 11:40 AM, J. Bruce Fields wrote:
>>> On Mon, Jan 10, 2022 at 10:50:53AM -0800, Dai Ngo wrote:
>>>> +		}
>>>> +		if (!state_expired(&lt, 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.
>> will remove.
>>
>>>> +			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.)
>> nfs4_anylock_conflict_locked scans cl_ownerstr_hashtbl which is protected
>> by the cl_lock.
> That doesn't answer the question.  Which, I confess, was muddled (I
> should have said "clp->cl_cs_lock", not "nn->client_lock".)
>
> Let me try it a different way.  You just checked that the client has
> some state, and that nobody is waiting for one of its locks.
>
> After you drop the cl_lock, how do you know that both of those things
> are still true?

After we drop the lock, if the client now has no state then it just
remains in memory until the courtesy client timeout expires then we
get rid of it.

For the race condition of lock conflict, we use the client->cl_cs_lock
to synchronize the laundromat and and lm_lock_conflict/nfsd4_fl_lock_conflict.
If the locking thread acquires the cl_cs_lock before the laundromat does
then the thread will be blocked and laundromat detects there is blocker
and expires the client. If the laundromat acquires the cl_cs_lock first
then NFSD4_COURTESY_CLIENT is set and nfsd4_fl_lock_conflict detects
this flag and sets the client to NFSD4_DESTROY_COURTESY_CLIENT.

-Dai


  reply	other threads:[~2022-01-13 19:51 UTC|newest]

Thread overview: 22+ 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 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
2022-01-13  8:51     ` dai.ngo
2022-01-13 15:42       ` J. Bruce Fields
2022-01-13 19:51         ` dai.ngo [this message]
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=f4c9b6fa-ef75-55b0-53dc-4830d6aef94e@oracle.com \
    --to=dai.ngo@oracle.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@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;
as well as URLs for NNTP newsgroup(s).