Linux NFS development
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: NeilBrown <neil@brown.name>
Cc: Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	linux-nfs@vger.kernel.org, Jeff Layton <jlayton@kernel.org>
Subject: Re: [PATCH 2/2] nfsd: stop pretending that we cache the SEQUENCE reply.
Date: Tue, 14 Oct 2025 10:25:39 -0400	[thread overview]
Message-ID: <b147f00f-c9f1-4e59-a735-afaf39c3f847@oracle.com> (raw)
In-Reply-To: <20251014000544.1567520-3-neilb@ownmail.net>

On 10/13/25 8:04 PM, NeilBrown wrote:
> From: NeilBrown <neil@brown.name>
> 
> nfsd does not cache the reply to a SEQUENCE.  When replayed, the
> SEQUENCE op itself is replay.


s/replay./replayed./


> So removing the code and comments which seem to imply that we do, and


s/removing/remove/


> detect the case of a SOLO sequence to avoid looking a the cache.


s/looking a the cache./looking at the slot replay cache./


> Signed-off-by: NeilBrown <neil@brown.name>
> ---
>  fs/nfsd/nfs4state.c |  7 ++-----
>  fs/nfsd/xdr4.h      | 20 ++++++--------------
>  2 files changed, 8 insertions(+), 19 deletions(-)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 1c01836e8507..b51a37ad70aa 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -3530,11 +3530,8 @@ nfsd4_enc_sequence_replay(struct nfsd4_compoundargs *args,


The function's comments (including its documenting comment) seem
repetitive. Let's remove the function's documenting comment, and
then disperse those remarks inside the function like so:

-       /* Encode the replayed sequence operation */
+	/* Encode the replayed SEQUENCE response from current slot values. */


>  		return op->status;
>  	if (args->opcnt == 1) {
>  		/*
> -		 * The original operation wasn't a solo sequence--we
> -		 * always cache those--so this retry must not match the
> -		 * original:
> +		 * We will simply replay the SEQUENCE.
>  		 */


The now empty set of braces here with just a comment is perhaps
confusing.


> -		op->status = nfserr_seq_false_retry;
>  	} else {


From above, add:

+		/*
+		 * Encode the uncached_rep error on the next
+		 * operation, and set resp->p and increment
+		 * resp->opcnt for nfs4svc_encode_compoundres.
+		 */


>  		op = &args->ops[resp->opcnt++];
>  		op->status = nfserr_retry_uncached_rep;
> @@ -3559,7 +3556,7 @@ nfsd4_replay_cache_entry(struct nfsd4_compoundres *resp,
>  	dprintk("--> %s slot %p\n", __func__, slot);
>  
>  	status = nfsd4_enc_sequence_replay(resp->rqstp->rq_argp, resp);
> -	if (status)
> +	if (status || !slot->sl_datalen)


This seems subtle. Maybe a comment could explain what this check
is trying to detect. I assume it is either the solo sequence case,
or the case where there is no replay cache?


>  		return status;
>  
>  	p = xdr_reserve_space(xdr, slot->sl_datalen);
> diff --git a/fs/nfsd/xdr4.h b/fs/nfsd/xdr4.h
> index ee0570cbdd9e..390bfb0ba13f 100644
> --- a/fs/nfsd/xdr4.h
> +++ b/fs/nfsd/xdr4.h
> @@ -923,25 +923,17 @@ struct nfsd4_compoundres {
>  	struct nfsd4_compound_state	cstate;
>  };
>  
> -static inline bool nfsd4_is_solo_sequence(struct nfsd4_compoundres *resp)
> -{
> -	struct nfsd4_compoundargs *args = resp->rqstp->rq_argp;
> -	return resp->opcnt == 1 && args->ops[0].opnum == OP_SEQUENCE;
> -}
> -
>  /*
>   * The session reply cache only needs to cache replies that the client
> - * actually asked us to.  But it's almost free for us to cache compounds
> - * consisting of only a SEQUENCE op, so we may as well cache those too.
> - * Also, the protocol doesn't give us a convenient response in the case
> - * of a replay of a solo SEQUENCE op that wasn't cached
> - * (RETRY_UNCACHED_REP can only be returned in the second op of a
> - * compound).
> + * actually asked us to.
> + * This doesn't apply to SEQUENCE.  We must always record in the slot
> + * that we have received a SEQUENCE, and must always respond
> + * successfully to a replayed successful SEQUENCE - that is handled
> + * separately from the sl_data cache.

Once is_solo_sequence is gone, I'm not convinced this is the right spot
for your new explanation. (ie, the comment seems sensible, but maybe it
belongs somewhere else).

The only thing this helper is doing is looking at how the client
set sa_cachethis in the original request, and that's already
obvious from the code -- no comment is needed. And maybe even this
helper could be removed, and the now smaller "if" statement can be
relocated to its only call site.


>   */
>  static inline bool nfsd4_cache_this(struct nfsd4_compoundres *resp)
>  {
> -	return (resp->cstate.slot->sl_flags & NFSD4_SLOT_CACHETHIS)
> -		|| nfsd4_is_solo_sequence(resp);
> +	return resp->cstate.slot->sl_flags & NFSD4_SLOT_CACHETHIS;
>  }
>  
>  static inline bool nfsd4_last_compound_op(struct svc_rqst *rqstp)


-- 
Chuck Lever

      parent reply	other threads:[~2025-10-14 14:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14  0:04 [PATCH 0/2] nfsd: fix up SEQUENCE replay NeilBrown
2025-10-14  0:04 ` [PATCH 1/2] nfsd: ensure SEQUENCE replay sends a valid reply NeilBrown
2025-10-14 13:44   ` Jeff Layton
2025-10-14 13:57   ` Chuck Lever
2025-10-14 14:57   ` Olga Kornievskaia
2025-10-14 22:49     ` NeilBrown
2025-10-14  0:04 ` [PATCH 2/2] nfsd: stop pretending that we cache the SEQUENCE reply NeilBrown
2025-10-14 13:47   ` Jeff Layton
2025-10-14 14:25   ` Chuck Lever [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b147f00f-c9f1-4e59-a735-afaf39c3f847@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=Dai.Ngo@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox