Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 30 Jun 2021 10:52:03 -0400
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
Message-ID: <20210630145203.GA20229@fieldses.org>
References: <20210603181438.109851-1-dai.ngo@oracle.com>
 <20210628202331.GC6776@fieldses.org>
 <dc71d572-d108-bcfc-e264-d96ef0de1b36@oracle.com>
 <fae4d46d-286c-013b-7606-97231fb1c17e@oracle.com>
 <20210630013529.GA6200@fieldses.org>
 <4d05112d-4d75-afeb-c7c6-ebba650d0f1b@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4d05112d-4d75-afeb-c7c6-ebba650d0f1b@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

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.