Re: [PATCH v6 04/14] nfsd: allow unrecognisable filehandle for foreign servers in COPY

[Chuck Lever <cel@kernel.org>]

On Sat, Nov 22, 2025 at 04:16:02PM -0500, Chuck Lever wrote:
> On Sat, Nov 22, 2025 at 11:47:02AM +1100, NeilBrown wrote:
> > From: NeilBrown <neil@brown.name>
> > 
> > RFC-7862 acknowledges that a filehandle provided as the source of an
> > inter-server copy might result in NFS4ERR_STALE when given to PUTFH, and
> > gives guidance on how this error can be ignored (section 15.2.3).
> > 
> > NFS4ERR_BADHANDLE is also a possible error in this circumstance if the
> > foreign server is running a different implementation of NFS than the
> > current one.
> 
> The RFC uses the terms "source" and "destination" server, fwiw.
> 
> It would be interesting to see if nfserr_badhandle can be triggered
> during an NFSD <-> NFSD copy.
> 
> 
> > This appears to be a simple omission in the RFC.
> 
> Perhaps. It might also be the result of the RFC authors giving
> implementers flexibility to innovate.
> 
> I would like to consult with the WG and possibly file an errata, or
> add this observation to the "NFSv4.2 COPY implementation experience"
> document I'm helping Olga with:
> 
> https://datatracker.ietf.org/doc/draft-cel-nfsv4-copy-implementation-experience/
> 
> They might want to consider NFS4ERR_MOVED as well.
> 
> 
> > There can be no harm in delaying a BADHANDLE error in the same situation
> > where we already delay STALE errors, and no harm in sending a locally
> > "bad" handle to a foreign server to request a COPY.
> 
> These are plausible claims. But IMO, they need firmer rationale.

My comments aren't terribly clear about this, but I agree that PUTFH
handling NFS4ERR_BADHANDLE is a concern when there is a subsequent
COPY operation in the COMPOUND.

I think we can't rely on the letter of RFC 7862, as you pointed out.
However, the spirit of RFC 7862 is that PUTFH mustn't fail if a
client presents a foreign file handle via a PUTFH that precedes a
COPY operation. The lack of BCP14 language specific to other status
codes shouldn't stop NFSD from handling other status codes as it
needs to (in fact, the absence of such language affords us the
opportunity of doing exactly that).

The reason for this potential PUTFH failure is an artifact of NFSD's
PUTFH implementation, which unconditionally invokes fh_verify.

I'm wondering if PUTFH needs to check for /specific/ status codes
from fh_verify before looking ahead in the incoming COMPOUND, or if
it ought to look ahead on /any/ failure of fh_verify.

And, is this patch a fix that needs to be backported to LTS kernels?
If so, then perhaps it needs to go before the previous patch.

(It seems like NFSv4.2 could have added a PUT_FOREIGN_FH operation
to avoid all this nonsense).

(I'll also note that now that our MAX_OPS_PER_COMPOUND has increased
and might increase again, moving the COPY look ahead checking out of
nfsd4_proc_compound is a huge bonus for handling large COMPOUNDs).


> > So extend the test in nfsd4_putfh to also check for nfserr_badhandle.
> > 
> > Signed-off-by: NeilBrown <neil@brown.name>
> > ---
> >  fs/nfsd/nfs4proc.c | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> > index 112e62b6b9c6..ae34b816371c 100644
> > --- a/fs/nfsd/nfs4proc.c
> > +++ b/fs/nfsd/nfs4proc.c
> > @@ -693,7 +693,8 @@ nfsd4_putfh(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> >  	       putfh->pf_fhlen);
> >  	ret = fh_verify(rqstp, &cstate->current_fh, 0, NFSD_MAY_BYPASS_GSS);
> >  #ifdef CONFIG_NFSD_V4_2_INTER_SSC
> > -	if (ret == nfserr_stale && inter_copy_offload_enable) {
> > +	if ((ret == nfserr_badhandle || ret == nfserr_stale) &&
> > +	    inter_copy_offload_enable) {
> >  		struct nfsd4_compoundargs *args = rqstp->rq_argp;
> >  		struct nfsd4_compoundres *resp = rqstp->rq_resp;
> >  
> > @@ -713,7 +714,11 @@ nfsd4_putfh(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> >  			 *  NOT return NFS4ERR_STALE for either
> >  			 *  operation.
> >  			 * We limit this to when there is a COPY
> > -			 * in the COMPOUND.
> > +			 * in the COMPOUND, and extend it to
> > +			 * also ignore NFS4ERR_BADHANDLE despite the
> > +			 * RFC not requiring this.  If the remote
> > +			 * server is running a different NFS implementation,
> > +			 * NFS4ERR_BADHANDLE is a likely error.
> >  			 */
> >  			ret = 0;
> >  		}
> > -- 
> > 2.50.0.107.gf914562f5916.dirty
> > 
> > 
> 
> -- 
> Chuck Lever
> 

-- 
Chuck Lever