From: "J. Bruce Fields" <bfields@fieldses.org>
To: dai.ngo@oracle.com
Cc: chuck.lever@oracle.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH RFC 1/1] nfsd: Initial implementation of NFSv4 Courteous Server
Date: Wed, 30 Jun 2021 10:52:03 -0400 [thread overview]
Message-ID: <20210630145203.GA20229@fieldses.org> (raw)
In-Reply-To: <4d05112d-4d75-afeb-c7c6-ebba650d0f1b@oracle.com>
On Wed, Jun 30, 2021 at 01:41:32AM -0700, dai.ngo@oracle.com wrote:
>
> On 6/29/21 6:35 PM, J. Bruce Fields wrote:
> >On Mon, Jun 28, 2021 at 09:40:56PM -0700, dai.ngo@oracle.com wrote:
> >>On 6/28/21 4:39 PM, dai.ngo@oracle.com wrote:
> >>>On 6/28/21 1:23 PM, J. Bruce Fields wrote:
> >>>>On Thu, Jun 03, 2021 at 02:14:38PM -0400, Dai Ngo wrote:
> >>>>>@@ -6875,7 +6947,12 @@ nfsd4_lock(struct svc_rqst *rqstp,
> >>>>>struct nfsd4_compound_state *cstate,
> >>>>> case -EAGAIN: /* conflock holds conflicting lock */
> >>>>> status = nfserr_denied;
> >>>>> dprintk("NFSD: nfsd4_lock: conflicting lock found!\n");
> >>>>>- nfs4_set_lock_denied(conflock, &lock->lk_denied);
> >>>>>+
> >>>>>+ /* try again if conflict with courtesy client */
> >>>>>+ if (nfs4_set_lock_denied(conflock, &lock->lk_denied)
> >>>>>== -EAGAIN && !retried) {
> >>>>>+ retried = true;
> >>>>>+ goto again;
> >>>>>+ }
> >>>>Ugh, apologies, this was my idea, but I just noticed it only
> >>>>handles conflicts
> >>>>from other NFSv4 clients. The conflicting lock could just as
> >>>>well come from
> >>>>NLM or a local process. So we need cooperation from the common
> >>>>locks.c code.
> >>>>
> >>>>I'm not sure what to suggest....
> >>One option is to use locks_copy_conflock/nfsd4_fl_get_owner to detect
> >>the lock being copied belongs to a courtesy client and schedule the
> >>laundromat to run to destroy the courtesy client. This option requires
> >>callers of vfs_lock_file to provide the 'conflock' argument.
> >I'm not sure I follow. What's the advantage of doing it this way?
>
> I'm not sure it's an advantage but I was trying to minimize changes to
> the fs code. The only change we need is to add the conflock argument
> to do_lock_file_wait to handle local lock conflicts.
Got it.
That's a clever but kind of unexpected use of lm_get_owner; I think it
could be confusing to a future reader. And I'd rather not require the
extra retry. A new lock callback is a complication, but at least it's
pretty obvious what it does.
> If you don't think we're going to get objection with the new callback,
> fl_expire_lock, then I will take that approach. We still need to add
> the conflock argument to do_lock_file_wait in this case.
Why is that?
--b.
next prev parent reply other threads:[~2021-06-30 14:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 18:14 [PATCH RFC 1/1] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2021-06-11 8:42 ` dai.ngo
2021-06-16 16:02 ` J. Bruce Fields
2021-06-16 16:32 ` Chuck Lever III
2021-06-16 19:25 ` dai.ngo
2021-06-16 19:29 ` Chuck Lever III
2021-06-16 20:30 ` Bruce Fields
2021-06-16 19:17 ` dai.ngo
2021-06-16 19:19 ` Calum Mackay
2021-06-16 19:27 ` dai.ngo
2021-06-24 14:02 ` J. Bruce Fields
2021-06-24 19:50 ` dai.ngo
2021-06-24 20:36 ` J. Bruce Fields
2021-06-28 20:23 ` J. Bruce Fields
2021-06-28 23:39 ` dai.ngo
2021-06-29 4:40 ` dai.ngo
2021-06-30 1:35 ` J. Bruce Fields
2021-06-30 8:41 ` dai.ngo
2021-06-30 14:52 ` J. Bruce Fields [this message]
2021-06-30 17:51 ` dai.ngo
2021-06-30 18:05 ` J. Bruce Fields
2021-06-30 18:49 ` dai.ngo
2021-06-30 18:55 ` J. Bruce Fields
2021-06-30 19:13 ` dai.ngo
2021-06-30 19:24 ` J. Bruce Fields
2021-06-30 23:48 ` dai.ngo
2021-07-01 1:16 ` J. Bruce Fields
2021-06-30 15:13 ` 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=20210630145203.GA20229@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--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;
as well as URLs for NNTP newsgroup(s).