src/sys/rpc, branch main

nfsd: Optionally enable use of M_EXTPG mbufs for read replies

2026-07-07T00:10:11Z

A test site determined that, for a Mellanox NIC which can handle M_EXTPG mbufs, an improvement of 5-15% for read rate could be achieved if the read reply was in M_EXTPG mbufs. A patch that tried to determine if the outbound NIC supported M_EXTPG mbufs (IFCAP_MEXTPG) did not pass review. However, it does appear that this can be useful for NFS-over-RDMA. (Which just happen to use NICs that do support M_EXTPG mbufs.) As such, this patch enables them is xp_extpg is set to true, which is never for now, but might be set true for RDMA or when vfs.nfsd.enable_mextpg is set non-zero. (It is 0 by default, so this is never enabled by default at this time.) Tested by: Greg Becker MFC after: 2 weeks

rpcsec_tls: Avoid a socket reference underflow in rpctls_server()

2026-06-15T15:54:30Z

The upcall_sockets tree owns a ref on any resident socket. When a socket is removed after a TLS handshake failure, rpctls_rpc_failed() thus calls soclose(). rpctls_server() does not acquire an extra ref to compensate for this. So, if the upcall fails, e.g., because rpc.tlsservd is not running, we'll call soclose() to drop the reference, but this effectively releases the xprt layer's reference. Fix the problem by explicitly acquiring a socket reference when adding a socket to the upcall tree. PR: 289734 Reviewed by: rmacklem, glebius MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57555

krpc: Get rid of KRPC_VNET macros

2026-05-03T21:25:06Z

When the krpc was vnet'd, the VNET macros were hidden behind macros that had the KRPC_ prefix on them. This was done because, at the time, it was thought that something other than vnet might be used for this. That has not happened and probably will not happen, so this patch replaces these obscuring macros with the regular vnet ones. There should be no semantics change caused by this commit. Discussed with: bz, glebius MFC after: 1 month

nfscl: Fix handling of gssd upcalls for the NFS client

2026-05-02T19:36:00Z

Without this patch, all upcalls to the gssd daemon are done in vnet0 (outside of any vnet jail). This does not work well, because a user principal's credential cache can be within the jail (/tmp/krb5cc_NNN in the jail's namespace). This patch modifies the client so that RPCs done from within vnet jails does an upcall to a gssd daemon running within the vnet jail. It required that the cache of uid->credential shorthands in the rpcsec_gss be vnet'd. The situation is still less than ideal and sec=krb5[ip] mounts that are visible within vnet jails is still not something I would recommend, but it can work ok with this patch. Vnet'ng the NFS client so that mounts can be done within vnet jails is probably more useful, but that will require additional work. Discussed with: glebius MFC after: 1 month

kgss: remove KGSS_VNET_* macros family

2026-04-25T02:55:45Z

The original idea was that something else than VNET(9) might be used for kgss in jails, but that is very unlikely to happen. Mechanical change done with sed+grep. No functional change. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D56560

rpcsec_gss(3): Fix a typo in a source code comment

2026-04-19T08:12:02Z

- s/verfier/verifier/ MFC after: 3 days

rpcsec_gss: Fix a stack overflow in svc_rpc_gss_validate()

2026-03-26T01:11:54Z

svc_rpc_gss_validate() copies the input message into a stack buffer without ensuring that the buffer is large enough. Sure enough, oa_length may be up to 400 bytes, much larger than the provided space. This enables an unauthenticated user to trigger an overflow and obtain remote code execution. Add a runtime check which verifies that the copy won't overflow. Approved by: so Security: FreeBSD-SA-26:08.rpcsec_gss Security: CVE-2026-4747 Reported by: Nicholas Carlini Reviewed by: rmacklem Fixes: a9148abd9da5d

clnt_bck.c: Delete a couple of old diagnostic printfs

2026-03-25T20:53:22Z

There were two debug printf()s that were left in the code while debugging the handling of callbacks over a NFSv4.1/4.2 backchannel was being done. This patch removes them, since they are no longer of benefit and cause "noise". Requested by: wollman MFC after: 2 weeks

rpc: Improve socket locking in svc_vc_accept()

2026-02-12T14:00:43Z

so_state modifications must be synchronized by the socket lock. For the listening socket this probably doesn't matter but for the child socket I think it's possible that this unlocked update clobbers a state transition if the nascent connection is being disconnected for some reason. Also fix the line which potentially clears SS_NBIO in the listening socket. It is unclear whether this code is used at all. Reviewed by: glebius MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D55247

rpc/xdr.h: make xdrproc_t always take two arguments

2026-01-23T10:35:32Z

The type of xdrproc_t is clearly defined in the comments as a function with two arguments, an XDR * and a void * (sometimes spelled caddr_t). It was initialy defined as: typedef bool_t (*xdrproc_t)(); At some point people started giving it a non-empty argument list. Unfortunatly, there has been widespread disagreement about how arguments are passed. There seems to have been a widespread view that it should be allowed to pass three argument function pointer to xdrproc_t. Most notable is xdr_string which takes a maximum length parameter. This lead to all sorts of prototypes (all of which have been present in the FreeBSD source tree): FreeBSD userspace (nominally from tirpc, but seemingly local): typedef bool_t (*xdrproc_t)(XDR *, ...); FreeBSD kernel, glibc: typedef bool_t (*xdrproc_t)(XDR *, void *, ...); rcp/xdr.h with _KERNEL defined (not used?): typedef bool_t (*xdrproc_t)(XDR *, void *, u_int); gssrpc (in krb5) and Linux kernel: typedef bool_t (*xdrproc_t)(XDR *, void *); For two argument functions on current ABIs, these all equivalent as these arguments are passed in registers regardless of decleration and definition, but we end up with two problems: - xdr_free((xdrproc_t)xdr_string, ...) calls xdr_string with no third argument and (at least on FreeBSD) may fail to free memory if the string is shorter than the value lying around in the third argument register. There are no instance of this in tree, but I found some with Debian code search, in particular in OpenAFS. - Under CheriABI, variadic arguments are passed in a separate, bounded array so theses prototypes aren't equilvalent to the non-variadic calling convention of the functions. The reality is that that xdr_string should not be cast to xdrproc_t and xdr_wrapstring should be used instead so we do not need to support this case. Instances of the former behavior are now extremely rare. With this change we bring FreeBSD in line with gssrpc and the Linux Kernel. Warnings about casts should now be correct and should be fixed. Bump __FreeBSD_version as some software required adaptation if it is declaring functions to cast to xdrproc_t. Update OpenZFS's workaround of this historic mess accordingly. Effort: CHERI upstreaming Sponsored by: Innovate UK Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54824