Re: [PATCH 1/2] nfsd: never defer requests during idmap lookup

[Anthony Iliopoulos <ailiop@suse.com>]

On Fri, Nov 28, 2025 at 11:09:52AM -0500, Chuck Lever wrote:
> 
> 
> On Thu, Nov 27, 2025, at 12:57 PM, Anthony Iliopoulos wrote:
> > During v4 request compound arg decoding, some ops (e.g. SETATTR) can
> > trigger idmap lookup upcalls. When those upcall responses get delayed
> > beyond the allowed time limit, cache_check() will mark the request for
> > deferral and cause it to be dropped.
> 
> The RFCs mandate that NFSv4 servers MUST NOT drop requests. What
> nfsd_dispatch() does in your case is return RPC_GARBAGE_ARGS to
> the client, which is distinct behavior from "dropping" a request.

It actually does drop the request, as pc_decode doesn't fail when this
happens.

For example in one instance of this issue which occurs while decoding a
SETATTR op that has FATTR4_WORD1_OWNER/GROUP set, nfsd4_decode_setattr
returns with status set to nfserr_badowner. This is set in op->status in
nfsd4_decode_compound, which will stop decoding further ops, but stil
returns true.

During nfsd4_decode_setattr, nfsd_map_name_to_[ug]id will end up calling
cache_check in idmap_lookup. What that does is basically:

- issue the upcall
- wait for completion with a short timeout
- attempt to defer the request if the upcall hasn't updated the cache entry
  in the meantime

That happens by calling svc_defer which will set RQ_DROPME on the
rqstp->rq_flags, causing nfsd_dispatch to return through the
out_update_drop, and in turn there will be no response sent out by
svc_process.

> > Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during
> > nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.
> 
> Help me understand how the upcall failure during XDR decoding is
> handled later? What server response is returned? Is it possible
> for the proc function to execute anyway with incorrect uid and
> gid values?

Without the next patch in this series, if the request isn't deferred it
will send back the NFS4ERR_BADOWNER status, which the nfs client will
map to -EINVAL and return to userspace.

With the next patch, it will return NFS4ERR_DELAY so that the client
will keep retrying the request until the id mapping completes.

In either case, even when the request is being dropped, the proc
function is never executed. While nfsd_dispatch will proceed to call the
pc_func, nfsd4_proc_compound checks for the op->status which was set in
the decoding stage, and jumps to nfsd4_encode_operation without calling
the op_func. In the particular instance of the SETATTR op, the encoder
will encode an empty attrsset bitmap to indicate the inability to set
any attributes.

Regards,
Anthony