On Mon, Apr 25, 2022 at 11:16:54AM -0700, dai.ngo@xxxxxxxxxx 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.
