Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 25 Apr 2022 15:19:15 -0400
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 0/7] NFSD: Initial implementation of NFSv4
 Courteous Server
Message-ID: <20220425191915.GF24825@fieldses.org>
References: <1650739455-26096-1-git-send-email-dai.ngo@oracle.com>
 <20220425161722.GC24825@fieldses.org>
 <20220425175327.GD24825@fieldses.org>
 <ed6893fa-fbb1-36a7-226a-4436edd34644@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ed6893fa-fbb1-36a7-226a-4436edd34644@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Mon, Apr 25, 2022 at 11:16:54AM -0700, dai.ngo@oracle.com wrote:
> 
> On 4/25/22 10:53 AM, J. Bruce Fields wrote:
> >I'm getting a few new pynfs failures after applying these.  I haven't
> >tried to investigage what's happening.
> >
> >--b.
> >
> >**************************************************
> >RENEW3   st_renew.testExpired                                     : FAILURE
> >            nfs4lib.BadCompoundRes: Opening file b'RENEW3-1':
> >            operation OP_OPEN should return NFS4_OK, instead got
> >            NFS4ERR_DELAY
> >LKU10    st_locku.testTimedoutUnlock                              : FAILURE
> >            nfs4lib.BadCompoundRes: Opening file b'LKU10-1':
> >            operation OP_OPEN should return NFS4_OK, instead got
> >            NFS4ERR_DELAY
> >CLOSE9   st_close.testTimedoutClose2                              : FAILURE
> >            nfs4lib.BadCompoundRes: Opening file b'CLOSE9-1':
> >            operation OP_OPEN should return NFS4_OK, instead got
> >            NFS4ERR_DELAY
> >CLOSE8   st_close.testTimedoutClose1                              : FAILURE
> >            nfs4lib.BadCompoundRes: Opening file b'CLOSE8-1':
> >            operation OP_OPEN should return NFS4_OK, instead got
> >            NFS4ERR_DELAY
> 
> with this patches, OPEN (v4.0 and v4.1) might have to handle NFS4ERR_DELAY
> if there is a reservation conflict. I had to modify open_confirm (v4.0) and
> open_create_file (v4.1) to handle the NFS4ERR_DELAY error.

Looking at your patch 2....

OK, my suggestion was: "in the case of a conflict, call
try_to_expire_client and queue_work(), then modify e.g.
nfs4_get_vfs_file to flush_workqueue() and then retry after unlocking
fi_lock."  You're returning DELAY instead of waiting for the workqueue.

After thinking on it a minute.... I like your way better.  It's simpler.
Any client has to handle DELAY on OPEN, for the delegation-conflict
case.  Maybe it's a little suboptimal, but so what, this is a very rare
case.

So, good thinking, let's stick with that idea.  We'll just need to fix
up pynfs some time.

--b.