Re: [PATCH] nfsd: allow setting SEQ4_STATUS_RECALLABLE_STATE_REVOKED

[Benjamin Coddington <bcodding@redhat.com>]

On 29 Aug 2023, at 16:35, Chuck Lever wrote:

> On Tue, Aug 29, 2023 at 12:26:56PM -0400, Benjamin Coddington wrote:
>> This patch sets the SEQ4_STATUS_RECALLABLE_STATE_REVOKED bit for a single
>> SEQUENCE response after writing "revoke" to the client's ctl file in procfs.
>> It has been generally useful to test various NFS client implementations, so
>> I'm sending it along for others to find and use.
>
> Intriguing!
>
> It looks to me like the client would probe its state and
> find nothing missing... fair enough.
>
> Would it be even more useful if the server administrator could
> actually revoke some state, rather than just pretending to?
> How difficult do you think that might be?

Probably not difficult, we'd just move some state to cl_revoked.  We'd need
to work out a syntax for it, or add another procfs file, but I don't have
any need for this.. yet.

> Or, conversely, what exactly can you test with this mechanism?

You can test how well the client performs TEST_STATEID for all its known
state, looking for unfairness or perhaps skipped state.  Doing a
TEST_STATEID walk can be a big lift for clients with a lot of delegations.

There's been recent reports of the linux client getting into a live jam
trying to use TEST_STATEID to satisfy a server that keeps setting this bit.
Its pretty hard to catch in the wild, and network captures are typically too
large to handle.  In the process of trying to optimize how the client
performs TEST_STATEID ops for all its state, this patch made it easier to
artificially trigger that client behavior.

I'm ambivalent about whether this goes upstream, but here it is if others
find it useful.

Ben