[RFC PATCH 1/1] nfsd: fix setting seq->maxslots for replay operations

[Olga Kornievskaia <okorniev@redhat.com>]

Here's the problem this patch attempts the solve. Client has an
established session and used no more one slot at some point but
currently is only using slot 0. Thus it's sending compount requests
with sa_highest_slotid=0. Now say the client sent an op (eg OPEN),
the server processed it, reply to OPEN is cached in the reply cache,
and connection gets reset. Upon reconnection the client resends OPEN
again with same sequence slotid, seqid, sa_highest_slotid=0.
Server replies out of the replay cache. But it sends the reply with
sr_highest_slotid=0. As the result, the client throws away any
slots it had above slot 0. Then when it needs to use more than
one slot, a compound is sent with a "new" slot seqid=1. Server replied
with NFS4ERR_SEQ_MISORDERED (because it never realized to told the
client to shrink its slot table).

The problem lies in how the server's seq->maxslots is managed. Normally,
in nfsd4_decode_sequence() seq->maxslots get set to whatever the
client sent in sa_highest_slotid+1. But then in nfsd4_sequence()
processing of the sequence when everything is checked and processed
(ie., it's not a replay operation), then seq->maxslots gets
reassessed again and gets set to max of session->se_target_maxslots
and seq->maxslots). Once nfsd4_sequence() is done only then later
it gets encoded and nfsd4_encode_sequence() put the value of
seq->maxslots into sr_highest_slotid reply.

Now, when the compound is a replay, then encoding is done within
the nfsd4_sequence() itself and seq->maxslots is set to whatever it
decodes from the call (ie., client sent sa_highest_slot=0 so it's 0+1).
Thus, the encoding function puts value of 0 into sr_highest_slotid.
nfsd4_sequence() would later reset the seq->maxslot but it's useless
as the encoding (of the wrong value) is done by then.

The proposed fix is to explicitly set the seq->maxslots and
seq->target_maxslots as it's done for normal sequence processing
prior to calling encoding of replay cache info.

---comment it probably needs a Fixes but I'm not sure what that
should be. As I think this is day0 behaviour.

Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
---
 fs/nfsd/nfs4state.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index fa073353f30b..4b4d067f20d0 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -4413,6 +4413,8 @@ nfsd4_sequence(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
 		cstate->slot = slot;
 		cstate->session = session;
 		cstate->clp = clp;
+		seq->maxslots = max(session->se_target_maxslots, seq->maxslots);
+		seq->target_maxslots = session->se_target_maxslots;
 		/* Return the cached reply status and set cstate->status
 		 * for nfsd4_proc_compound processing */
 		status = nfsd4_replay_cache_entry(resp, seq);
-- 
2.47.3