On 2/7/25 4:53 PM, Jeff Layton wrote: > ESERVERFAULT means that the server sent a successful and legitimate > reply, but the session info didn't match what was expected. Don't > increment the seq_nr in that case. > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > --- > fs/nfsd/nfs4callback.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c > index 1e601075fac02bd5f01ff89d9252ab23d08c4fd9..d307ca1771bd1eca8f60b62a74170e71e5acf144 100644 > --- a/fs/nfsd/nfs4callback.c > +++ b/fs/nfsd/nfs4callback.c > @@ -1369,7 +1369,11 @@ static bool nfsd4_cb_sequence_done(struct rpc_task *task, struct nfsd4_callback > ret = true; > break; > case -ESERVERFAULT: > - ++session->se_cb_seq_nr[cb->cb_held_slot]; > + /* > + * Call succeeded, but CB_SEQUENCE reply failed sanity checks. > + * The client has gone insane. Mark the BC faulty, since there > + * isn't much else we can do. > + */ I'm chewing on the "gone insane" remark. Since I'm tagging a few nits in other spots: perhaps this comment could explain in more specific detail why the server cannot trust this CB_SEQUENCE response. Maybe: /* * Call succeeded, but the session, slot index, or slot * sequence number in the response do not match the same * in the server's call. The sequence information is thus * untrustworthy. */ That's wordy, but you get the idea. Even better if we can find some relevant spec language. > nfsd4_mark_cb_fault(cb->cb_clp); > break; > case 1: > -- Chuck Lever
