kernel/include/linux/sunrpc/svc.h, branch linux-6.16.y

SUNRPC: Bump the maximum payload size for the server

2025-05-15T20:16:28Z

Increase the maximum server-side RPC payload to 4MB. The default remains at 1MB. An API to adjust the operational maximum was added in 2006 by commit 596bbe53eb3a ("[PATCH] knfsd: Allow max size of NFSd payload to be configured"). To adjust the operational maximum using this API, shut down the NFS server. Then echo a new value into: /proc/fs/nfsd/max_block_size And restart the NFS server. Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever

sunrpc: Remove the RPCSVC_MAXPAGES macro

2025-05-15T20:16:27Z

It is no longer used. Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever

SUNRPC: Remove svc_rqst :: rq_vec

2025-05-15T20:16:25Z

Clean up: This array is no longer used. On a system with 8-byte pointers and 4KB pages, pahole reports that the rq_vec[] array accounts for 4144 bytes. Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

SUNRPC: Remove svc_fill_write_vector()

2025-05-15T20:16:25Z

Clean up: This API is no longer used. Signed-off-by: Chuck Lever

NFSD: De-duplicate the svc_fill_write_vector() call sites

2025-05-15T20:16:23Z

All three call sites do the same thing. I'm struggling with this a bit, however. struct xdr_buf is an XDR layer object and unmarshaling a WRITE payload is clearly a task intended to be done by the proc and xdr functions, not by VFS. This feels vaguely like a layering violation. Signed-off-by: Chuck Lever

sunrpc: Replace the rq_bvec array with dynamically-allocated memory

2025-05-15T20:16:23Z

As a step towards making NFSD's maximum rsize and wsize variable at run-time, replace the fixed-size rq_bvec[] array in struct svc_rqst with a chunk of dynamically-allocated memory. The rq_bvec[] array contains enough bio_vecs to handle each page in a maximum size RPC message. On a system with 8-byte pointers and 4KB pages, pahole reports that the rq_bvec[] array is 4144 bytes. This patch replaces that array with a single 8-byte pointer field. Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever

sunrpc: Replace the rq_pages array with dynamically-allocated memory

2025-05-15T20:16:22Z

As a step towards making NFSD's maximum rsize and wsize variable at run-time, replace the fixed-size rq_vec[] array in struct svc_rqst with a chunk of dynamically-allocated memory. On a system with 8-byte pointers and 4KB pages, pahole reports that the rq_pages[] array is 2080 bytes. This patch replaces that with a single 8-byte pointer field. Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever

sunrpc: Add a helper to derive maxpages from sv_max_mesg

2025-05-15T20:16:21Z

This page count is to be used to allocate various arrays of pages and bio_vecs, replacing the fixed RPCSVC_MAXPAGES value. The documenting comment is somewhat stale -- of course NFSv4 COMPOUND procedures may have multiple payloads. Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever

sunrpc: remove all connection limit configuration

2025-01-06T14:37:36Z

Now that the connection limit only apply to unconfirmed connections, there is no need to configure it. So remove all the configuration and fix the number of unconfirmed connections as always 64 - which is now given a name: XPT_MAX_TMP_CONN Signed-off-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever

nfsd: don't use sv_nrthreads in connection limiting calculations.

2025-01-06T14:37:36Z

The heuristic for limiting the number of incoming connections to nfsd currently uses sv_nrthreads - allowing more connections if more threads were configured. A future patch will allow number of threads to grow dynamically so that there will be no need to configure sv_nrthreads. So we need a different solution for limiting connections. It isn't clear what problem is solved by limiting connections (as mentioned in a code comment) but the most likely problem is a connection storm - many connections that are not doing productive work. These will be closed after about 6 minutes already but it might help to slow down a storm. This patch adds a per-connection flag XPT_PEER_VALID which indicates that the peer has presented a filehandle for which it has some sort of access. i.e the peer is known to be trusted in some way. We now only count connections which have NOT been determined to be valid. There should be relative few of these at any given time. If the number of non-validated peer exceed a limit - currently 64 - we close the oldest non-validated peer to avoid having too many of these useless connections. Note that this patch significantly changes the meaning of the various configuration parameters for "max connections". The next patch will remove all of these. Signed-off-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever