kernel.git/net/sunrpc/clnt.c, branch linux-rolling-stable

net: Convert proto_ops connect() callbacks to use sockaddr_unsized

2025-11-05T03:10:32Z

Update all struct proto_ops connect() callback function prototypes from "struct sockaddr *" to "struct sockaddr_unsized *" to avoid lying to the compiler about object sizes. Calls into struct proto handlers gain casts that will be removed in the struct proto conversion patch. No binary changes expected. Signed-off-by: Kees Cook Link: https://patch.msgid.link/20251104002617.2752303-3-kees@kernel.org Signed-off-by: Jakub Kicinski

net: Convert proto_ops bind() callbacks to use sockaddr_unsized

2025-11-05T03:10:32Z

Update all struct proto_ops bind() callback function prototypes from "struct sockaddr *" to "struct sockaddr_unsized *" to avoid lying to the compiler about object sizes. Calls into struct proto handlers gain casts that will be removed in the struct proto conversion patch. No binary changes expected. Signed-off-by: Kees Cook Link: https://patch.msgid.link/20251104002617.2752303-2-kees@kernel.org Signed-off-by: Jakub Kicinski

rpc_create_client_dir(): return 0 or -E...

2025-07-03T02:44:55Z

Callers couldn't care less which dentry did we get - anything valid is treated as success. Reviewed-by: Jeff Layton Signed-off-by: Al Viro

sunrpc: don't immediately retransmit on seqno miss

2025-05-19T14:14:29Z

RFC2203 requires that retransmitted messages use a new gss sequence number, but the same XID. This means that if the server is just slow (e.x. overloaded), the client might receive a response using an older seqno than the one it has recorded. Currently, Linux's client immediately retransmits in this case. However, this leads to a lot of wasted retransmits until the server eventually responds faster than the client can resend. Client -> SEQ 1 -> Server Client -> SEQ 2 -> Server Client <- SEQ 1 <- Server (misses, expecting seqno = 2) Client -> SEQ 3 -> Server (immediate retransmission on miss) Client <- SEQ 2 <- Server (misses, expecting seqno = 3) Client -> SEQ 4 -> Server (immediate retransmission on miss) ... and so on ... This commit makes it so that we ignore messages with bad checksums due to seqnum mismatch, and rely on the usual timeout behavior for retransmission instead of doing so immediately. Signed-off-by: Nikhil Jha Acked-by: Chuck Lever Signed-off-by: Anna Schumaker

SUNRPC: rpc_clnt_set_transport() must not change the autobind setting

2025-03-26T16:17:46Z

The autobind setting was supposed to be determined in rpc_create(), since commit c2866763b402 ("SUNRPC: use sockaddr + size when creating remote transport endpoints"). Reviewed-by: Jeff Layton Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust

NFS: Treat ENETUNREACH errors as fatal in containers

2025-03-21T16:44:19Z

Propagate the NFS_MOUNT_NETUNREACH_FATAL flag to work with the generic NFS client. If the flag is set, the client will receive ENETDOWN and ENETUNREACH errors from the RPC layer, and is expected to treat them as being fatal. Signed-off-by: Trond Myklebust Reviewed-by: Jeff Layton Tested-by: Jeff Layton Acked-by: Chuck Lever

SUNRPC: do not retry on EKEYEXPIRED when user TGT ticket expired

2025-01-22T20:53:31Z

When a user TGT ticket expired, gssd returns EKEYEXPIRED to the RPC layer for the upcall to create the security context. The RPC layer then retries the upcall twice before returning the EKEYEXPIRED to the NFS layer. This results in three separate TCP connections to the NFS server being created by gssd for each RPC request. These connections are not used and left in TIME_WAIT state. Note that for RPC call that uses machine credential, gssd automatically renews the ticket. But for a regular user the ticket needs to be renewed by the user before access to the krb5 share is allowed. This patch removes the retries by RPC on EKEYEXPIRED so that these unused TCP connections are not created. Reproducer: $ kinit -l 1m $ sleep 65 $ cd /mnt/krb5share $ netstat -na |grep TIME_WAIT Signed-off-by: Dai Ngo Signed-off-by: Anna Schumaker

SUNRPC: display total RPC tasks for RPC client

2025-01-13T18:27:25Z

Display the total number of RPC tasks, including tasks waiting on workqueue and wait queues, for rpc_clnt. Signed-off-by: Dai Ngo Signed-off-by: Anna Schumaker

SUNRPC: only put task on cl_tasks list after the RPC call slot is reserved.

2025-01-13T18:27:25Z

Under heavy write load, we've seen the cl_tasks list grows to millions of entries. Even though the list is extremely long, the system still runs fine until the user wants to get the information of all active RPC tasks by doing: When this happens, tasks_start acquires the cl_lock to walk the cl_tasks list, returning one entry at a time to the caller. The cl_lock is held until all tasks on this list have been processed. While the cl_lock is held, completed RPC tasks have to spin wait in rpc_task_release_client for the cl_lock. If there are millions of entries in the cl_tasks list it will take a long time before tasks_stop is called and the cl_lock is released. The spin wait tasks can use up all the available CPUs in the system, preventing other jobs to run, this causes the system to temporarily lock up. This patch fixes this problem by delaying inserting the RPC task on the cl_tasks list until the RPC call slot is reserved. This limits the length of the cl_tasks to the number of call slots available in the system. Signed-off-by: Dai Ngo Signed-off-by: Anna Schumaker

SUNRPC: remove call_allocate() BUG_ONs

2024-09-23T19:03:30Z

Remove BUG_ON if p_arglen=0 to allow RPC with void arg. Remove BUG_ON if p_replen=0 to allow RPC with void return. The former was needed for the first revision of the LOCALIO protocol which had an RPC that took a void arg: /* raw RFC 9562 UUID */ typedef u8 uuid_t; program NFS_LOCALIO_PROGRAM { version LOCALIO_V1 { void NULL(void) = 0; uuid_t GETUUID(void) = 1; } = 1; } = 400122; The latter is needed for the final revision of the LOCALIO protocol which has a UUID_IS_LOCAL RPC which returns a void: /* raw RFC 9562 UUID */ typedef u8 uuid_t; program NFS_LOCALIO_PROGRAM { version LOCALIO_V1 { void NULL(void) = 0; void UUID_IS_LOCAL(uuid_t) = 1; } = 1; } = 400122; There is really no value in triggering a BUG_ON in response to either of these previously unsupported conditions. NeilBrown would like the entire 'if (proc->p_proc != 0)' branch removed (not just the one BUG_ON that must be removed for LOCALIO's immediate needs of returning void). Signed-off-by: Mike Snitzer Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker