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;
From:   Benjamin Coddington <bcodding@redhat.com>
To:     Chuck Lever <chuck.lever@oracle.com>
Cc:     Jeff Layton <jlayton@kernel.org>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfsd: Fix race to FREE_STATEID and cl_revoked
Date:   Fri, 04 Aug 2023 11:16:02 -0400
Message-ID: <FE888F7B-80EC-4BF9-AA45-BAF5E28513C2@redhat.com>
In-Reply-To: <ZM0TF/rOFOxlaA+p@tissot.1015granger.net>
References: <c0fe2b35900938943048340ef70fc12282fe1af8.1691160604.git.bcodding@redhat.com>
 <ZM0TF/rOFOxlaA+p@tissot.1015granger.net>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 4 Aug 2023, at 11:02, Chuck Lever wrote:

> On Fri, Aug 04, 2023 at 10:52:20AM -0400, Benjamin Coddington wrote:
>> We have some reports of linux NFS clients that cannot satisfy a linux knfsd
>> server that always sets SEQ4_STATUS_RECALLABLE_STATE_REVOKED even though
>> those clients repeatedly walk all their known state using TEST_STATEID and
>> receive NFS4_OK for all.
>>
>> Its possible for revoke_delegation() to set NFS4_REVOKED_DELEG_STID, then
>> nfsd4_free_stateid() finds the delegation and returns NFS4_OK to
>> FREE_STATEID.  Afterward, revoke_delegation() moves the same delegation to
>> cl_revoked.  This would produce the observed client/server effect.
>>
>> Fix this by ensuring that the setting of sc_type to NFS4_REVOKED_DELEG_STID
>> and move to cl_revoked happens within the same cl_lock.  This will allow
>> nfsd4_free_stateid() to properly remove the delegation from cl_revoked.
>>
>> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2217103
>> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2176575
>> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
>
> Hi Ben, does this fix deserve:
>
> Cc: stable@vger.kernel.org # v4.17+

Yes, that's probably appropriate.

Ben