aboutsummaryrefslogtreecommitdiff
path: root/sys/rpc
Commit message (Collapse)AuthorAgeFilesLines
* svc_rpcsec_gss.c: Separate out the non-vnet initializationRick Macklem2023-03-011-11/+24
| | | | | | | | | | | | | | | Without this patch, a single initialization function was used to initialize both the vnet'd and non-vnet'd data. This patch separates out the non-vnet'd initializations into a separate function invoked by SYSINIT(). This avoids use of IS_DEFAULT_VNET() in the initialization functions and also configures the non-vnet'd initialization function to be called first, although ordering is not currently needed. Reviewed by: glebius MFC after: 3 months Differential Revision: https://reviews.freebsd.org/D38749
* nfsd: Add VNET_SYSUNINIT() macros for vnet cleanupRick Macklem2023-02-203-12/+24
| | | | | | | | | | | | | | | Commit ed03776ca7f4 enabled the vnet front end macros. As such, for kernels built with the VIMAGE option will malloc data and initialize locks on a per-vnet basis, typically via a VNET_SYSINIT(). This patch adds VNET_SYSUNINIT() macros to do the frees of the per-vnet malloc'd data and destroys of per-vnet locks. It also removes the mtx_lock/mtx_unlock calls from nfsrvd_cleancache(), since they are not needed. Discussed with: bz, jamie MFC after: 3 months
* nfsd: Enable the NFSD_VNET vnet front end macrosRick Macklem2023-02-183-15/+11
| | | | | | | | | | | | | | | | | | | | | | | | Several commits have added front end macros for the vnet macros to the NFS server, krpc and kgssapi. These macros are now null, but this patch changes them to front end the vnet macros. With this commit, many global variables in the code become vnet'd, so that nfsd(8), nfsuserd(8), rpc.tlsservd(8) and gssd(8) can run in a vnet prison, once enabled. To run the NFS server in a vnet prison still requires a couple of patches (in D37741 and D38371) that allow mountd(8) to export file systems from within a vnet prison. Once these are committed to main, a small patch to kern_jail.c allowing "allow.nfsd" without VNET_NFSD defined will allow the NFS server to run in a vnet prison. One area that still needs to be settled is cleanup when a prison is removed. Without this, everything should work except there will be a leak of malloc'd data and mutex locks when a vnet prison is removed. MFC after: 3 months
* krpc: Replace !jailed() with IS_DEFAULT_VNET()Rick Macklem2023-02-161-1/+1
| | | | | | | Since svcpool_create() is now called from an initialization function, !jailed() no longer works. Replace it with IS_DEFAULT_VNET(). MFC after: 3 months
* kgssapi: Add macros so that gssd(8) can run in vnet prisonRick Macklem2023-02-151-40/+54
| | | | | | | | | | | | | Commit 7344856e3a6d added a lot of macros that will front end vnet macros so that nfsd(8) can run in vnet prison. This patch adds similar macros named KGSS_VNETxxx so that the gssd(8) daemon can run in a vnet prison, once the macros front end the vnet ones. For now, they are null macros. This is the last commit that adds macros. The next step is to change the macros to front end the vnet ones. MFC after: 3 months
* krpc: Add macros so that rpc.tlsservd can run in vnet prisonRick Macklem2023-02-152-57/+125
| | | | | | | | | | Commit 7344856e3a6d added a lot of macros that will front end vnet macros so that nfsd(8) can run in vnet prison. This patch adds similar macros named KRPC_VNETxxx so that the rpc.tlsservd(8) daemon can run in a vnet prison, once the macros front end the vnet ones. For now, they are null macros. MFC after: 3 months
* krpc: Remove VNET_NFSD #ifdefsRick Macklem2023-02-141-12/+2
| | | | | | | The consensus is that the VNET_NFSD kernel option is not needed, so this commit removes its use from the kernel RPC. MFC after: 3 months
* rpc: ansifyMateusz Guzik2023-02-133-14/+6
| | | | | Reported by: clang 15 Sponsored by: Rubicon Communications, LLC ("Netgate")
* krpc: Allow mountd/nfsd to optionally run in a jailRick Macklem2022-12-184-4/+25
| | | | | | | | | | | | | | | | | | | | | | This patch modifies the kernel RPC so that it will allow mountd/nfsd to run inside of a vnet jail. Running mountd/nfsd inside a vnet jail will be enabled via a new kernel build option called VNET_NFSD, which will be implemented in future commits. Although I suspect cr_prison can be set from the credentials of the current thread unconditionally, I #ifdef'd the code VNET_NFSD and only did this for the jailed case mainly to document that it is only needed for use in a jail. The TLS support code has not yet been modified to work in a jail. That is planned as future development after the basic VNET_NFSD support is in the kernel. This patch should not result in any semantics change until VNET_NFSD is implemented and used in a kernel configuration. MFC after: 4 months
* clnt_vc.c: Replace msleep() with pause() to avoid assert panicRick Macklem2022-10-141-3/+3
| | | | | | | | | | | | | | | | An msleep() in clnt_vc.c used a global "fake_wchan" wchan argument along with the mutex in a CLIENT structure. As such, it was possible to use different mutexes for the same wchan and cause a panic assert. Since this is in a rarely executed code path, the assert panic was only recently observed. Since "fake_wchan" never gets a wakeup, this msleep() can be replaced with a pause() to avoid the panic assert, which is what this patch does. Reviewed by: kib, markj MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D36977
* nfsd: Allow multiple instances of rpc.tlsservdRick Macklem2022-08-224-47/+122
| | | | | | | | | | | | | During a discussion with someone working on NFS-over-TLS for a non-FreeBSD platform, we agreed that a single server daemon for TLS handshakes could become a bottleneck when an NFS server first boots, if many concurrent NFS-over-TLS connections are attempted. This patch modifies the kernel RPC code so that it can handle multiple rpc.tlsservd daemons. A separate commit currently under review as D35886 for the rpc.tlsservd daemon.
* protosw: refactor protosw and domain static declaration and loadGleb Smirnoff2022-08-173-7/+7
| | | | | | | | | | | | | | | | | | | o Assert that every protosw has pr_attach. Now this structure is only for socket protocols declarations and nothing else. o Merge struct pr_usrreqs into struct protosw. This was suggested in 1996 by wollman@ (see 7b187005d18ef), and later reiterated in 2006 by rwatson@ (see 6fbb9cf860dcd). o Make struct domain hold a variable sized array of protosw pointers. For most protocols these pointers are initialized statically. Those domains that may have loadable protocols have spacers. IPv4 and IPv6 have 8 spacers each (andre@ dff3237ee54ea). o For inetsw and inet6sw leave a comment noting that many protosw entries very likely are dead code. o Refactor pf_proto_[un]register() into protosw_[un]register(). o Isolate pr_*_notsupp() methods into uipc_domain.c Reviewed by: melifaro Differential revision: https://reviews.freebsd.org/D36232
* Adjust authnone_create() definition to avoid clang 15 warningDimitry Andric2022-07-241-1/+1
| | | | | | | | | | | | | | | With clang 15, the following -Werror warning is produced: sys/rpc/auth_none.c:106:16: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] authnone_create() ^ void This is because authnone_create() is declared with a (void) argument list, but defined with an empty argument list. Make the definition match the declaration. MFC after: 3 days
* Adjust svc_vc_null() definition to avoid clang 15 warningDimitry Andric2022-07-241-1/+1
| | | | | | | | | | | | | | | With clang 15, the following -Werror warning is produced: sys/rpc/svc_vc.c:1078:12: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] svc_vc_null() ^ void This is because svc_vc_null() is declared with a (void) argument list, but defined with an empty argument list. Make the definition match the declaration. MFC after: 3 days
* Adjust local_rpcb() definition to avoid clang 15 warningDimitry Andric2022-07-241-1/+1
| | | | | | | | | | | | | | | With clang 15, the following -Werror warning is produced: sys/rpc/rpcb_clnt.c:439:11: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] local_rpcb() ^ void This is because local_rpcb() is declared with a (void) argument list, but defined with an empty argument list. Make the definition match the declaration. MFC after: 3 days
* krpc: Fix NFS-over-TLS for KTLS1.3Rick Macklem2022-05-152-18/+15
| | | | | | | | | | | | | | | | | | | | When NFS-over-TLS uses KTLS1.3, the client can receive post-handshake handshake records. These records can be safely thown away, but are not handled correctly via the rpctls_ct_handlerecord() upcall to the daemon. Commit 373511338d95 changed soreceive_generic() so that it will only return ENXIO for Alert records when MSG_TLSAPPDATA is specified. As such, the post-handshake handshake records will be returned to the krpc. This patch modifies the krpc so that it will throw these records away, which seems sufficient to make NFS-over-TLS work with KTLS1.3. This change has no effect on the use of KTLS1.2, since it does not generate post-handshake handshake records. MFC after: 2 weeks
* sockets: use socket buffer mutexes in struct socket directlyGleb Smirnoff2022-05-122-2/+2
| | | | | | | | | | | | | | | | | | Since c67f3b8b78e the sockbuf mutexes belong to the containing socket, and socket buffers just point to it. In 74a68313b50 macros that access this mutex directly were added. Go over the core socket code and eliminate code that reaches the mutex by dereferencing the sockbuf compatibility pointer. This change requires a KPI change, as some functions were given the sockbuf pointer only without any hint if it is a receive or send buffer. This change doesn't cover the whole kernel, many protocols still use compatibility pointers internally. However, it allows operation of a protocol that doesn't use them. Reviewed by: markj Differential revision: https://reviews.freebsd.org/D35152
* svc_vc_rendezvous_stat: eliminiate write only variable statWarner Losh2022-04-051-2/+1
| | | | Sponsored by: Netflix
* clnt_vc_destroy: eliminiate write only variable statWarner Losh2022-04-051-2/+1
| | | | Sponsored by: Netflix
* rpc(3): Fix two typos in source code commentsGordon Bergling2022-04-021-1/+1
| | | | | | | - s/alloctaed/allocated/ Obtained from: NetBSD MFC after: 3 days
* sys/rpc: Use C99 fixed-width integer types.John Baldwin2021-12-283-4/+4
| | | | | | | No functional change. Reviewed by: imp, emaste Differential Revision: https://reviews.freebsd.org/D33640
* rpc: Delete AUTH_NEEDS_TLS(_MUTUAL_HOST) auth_stat valuesRick Macklem2021-12-231-6/+0
| | | | | | | | | | | I thought that these new auth_stat values had been agreed upon by the IETF NFSv4 working group, but that no longer is the case. As such, delete them and use AUTH_TOOWEAK instead. Leave the code that uses these new auth_stat values in the sources #ifdef notnow, in case they are defined in the future. MFC after: 1 week
* mbuf: Only allow extpg mbufs if the system has a direct mapMark Johnston2021-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Some upcoming changes will modify software checksum routines like in_cksum() to operate using m_apply(), which uses the direct map to access packet data for unmapped mbufs. This approach of course does not work on platforms without a direct map, so we have to disallow the use of unmapped mbufs on such platforms. I believe this is the right tradeoff: we only configure KTLS on amd64 and arm64 today (and one KTLS consumer, NFS TLS, requires a direct map already), and the use of unmapped mbufs with plain sendfile is a recent optimization. If need be, m_apply() could be modified to create CPU-private mappings of extpg mbuf pages as a fallback. So, change mb_use_ext_pgs to be hard-wired to zero on systems without a direct map. Note that PMAP_HAS_DMAP is not a compile-time constant on some systems, so the default value of mb_use_ext_pgs has to be determined during boot. Reviewed by: jhb Discussed with: gallatin MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32940
* Don't require the socket lock for sorele().John Baldwin2021-11-092-2/+0
| | | | | | | | | | | | | | | | | | | | Previously, sorele() always required the socket lock and dropped the lock if the released reference was not the last reference. Many callers locked the socket lock just before calling sorele() resulting in a wasted lock/unlock when not dropping the last reference. Move the previous implementation of sorele() into a new sorele_locked() function and use it instead of sorele() for various places in uipc_socket.c that called sorele() while already holding the socket lock. The sorele() macro now uses refcount_release_if_not_last() try to drop the socket reference without locking the socket. If that shortcut fails, it locks the socket and calls sorele_locked(). Reviewed by: kib, markj Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D32741
* rpc: Convert an SOLISTENING check to an assertionMark Johnston2021-09-171-5/+3
| | | | | | | Per the comment, this socket should always be a listening socket. MFC after: 1 week Sponsored by: The FreeBSD Foundation
* Fix a common typo in source code commentsGordon Bergling2021-09-041-1/+1
| | | | | | - s/existant/existent/ MFC after: 3 days
* rpc: Make function tables constMark Johnston2021-08-1415-24/+24
| | | | | | | No functional change intended. MFC after: 1 week Sponsored by: The FreeBSD Foundation
* Consistently use the SOLISTENING() macroMark Johnston2021-06-141-1/+1
| | | | | | | | | | Some code was using it already, but in many places we were testing SO_ACCEPTCONN directly. As a small step towards fixing some bugs involving synchronization with listen(2), make the kernel consistently use SOLISTENING(). No functional change intended. MFC after: 1 week Sponsored by: The FreeBSD Foundation
* krpc: Acquire ref count of CLIENT for backchannel useRick Macklem2021-06-113-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Michael Dexter <editor@callfortesting.org> reported a crash in FreeNAS, where the first argument to clnt_bck_svccall() was no longer valid. This argument is a pointer to the callback CLIENT structure, which is free'd when the associated NFSv4 ClientID is free'd. This appears to have occurred because a callback reply was still in the socket receive queue when the CLIENT structure was free'd. This patch acquires a reference count on the CLIENT that is not CLNT_RELEASE()'d until the socket structure is destroyed. This should guarantee that the CLIENT structure is still valid when clnt_bck_svccall() is called. It also adds a check for closed or closing to clnt_bck_svccall() so that it will not process the callback RPC reply message after the ClientID is free'd. Comments by: mav MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D30153
* nfsd: Fix the failure return for non-fh NFSv4 operationsRick Macklem2021-06-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | Without this patch, nfsd_checkrootexp() returns failure and then the NFSv4 operation would reply NFSERR_WRONGSEC. RFC5661 Sec. 2.6 only allows a few NFSv4 operations, none of which call nfsv4_checktootexp(), to return NFSERR_WRONGSEC. This patch modifies nfsd_checkrootexp() to return the error instead of a boolean and sets the returned error to an RPC layer AUTH_ERR, as discussed on nfsv4@ietf.org. The patch also fixes nfsd_errmap() so that the pseudo error NFSERR_AUTHERR is handled correctly such that an RPC layer AUTH_ERR is replied to the NFSv4 client. The two new "enum auth_stat" values have not yet been assigned by IANA, but are the expected next two values. The effect on extant NFSv4 clients of this change appears limited to reporting a different failure error when a mount that does not use adequate security is attempted. MFC after: 2 weeks
* rpcsec_gss: Use a designated initializer for rpc_gss_opsMark Johnston2021-05-261-5/+5
| | | | | | | No functional change intended. MFC after: 1 week Sponsored by: The FreeBSD Foundation
* nfsd: fix a NFSv4.1 Linux client mount stuck in CLOSE_WAITRick Macklem2021-04-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | It was reported that a NFSv4.1 Linux client mount against a FreeBSD12 server was hung, with the TCP connection in CLOSE_WAIT state on the server. When a NFSv4.1/4.2 mount is done and the back channel is bound to the TCP connection, the soclose() is delayed until a new TCP connection is bound to the back channel, due to a reference count being held on the SVCXPRT structure in the krpc for the socket. Without the soclose() call, the socket will remain in CLOSE_WAIT and this somehow caused the Linux client to hang. This patch adds calls to soshutdown(.., SHUT_WR) that are performed when the server side krpc sees that the socket is no longer usable. Since this can be done before the back channel is bound to a new TCP connection, it allows the TCP connection to proceed to CLOSED state. PR: 254590 Reported by: jbreitman@tildenparkcapital.com Reviewed by: tuexen Comments by: kevans MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D29526
* nfsv4 client: do the BindConnectionToSession as requiredRick Macklem2021-04-113-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | During a recent testing event, it was reported that the NFSv4.1/4.2 server erroneously bound the back channel to a new TCP connection. RFC5661 specifies that the fore channel is implicitly bound to a new TCP connection when an RPC with Sequence (almost any of them) is done on it. For the back channel to be bound to the new TCP connection, an explicit BindConnectionToSession must be done as the first RPC on the new connection. Since new TCP connections are created by the "reconnect" layer (sys/rpc/clnt_rc.c) of the krpc, this patch adds an optional upcall done by the krpc whenever a new connection is created. The patch also adds the specific upcall function that does a BindConnectionToSession and configures the krpc to call it when required. This is necessary for correct interoperability with NFSv4.1/NFSv4.2 servers when the nfscbd daemon is running. If doing NFSv4.1/NFSv4.2 mounts without this patch, it is recommended that the nfscbd daemon not be running and that the "pnfs" mount option not be specified. PR: 254840 Comments by: asomers MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D29475
* nfs-over-tls: handle res.gid.gid_val correctly for memory allocationRick Macklem2021-01-121-0/+2
| | | | | | | | | | | | | | When the server side nfs-over-tls does an upcall to rpc.tlsservd(8) for the handshake and the rpc.tlsservd "-u" command line option has been specified, a list of gids may be returned. The list will be returned in malloc'd memory pointed to by res.gid.gid_val. To ensure the malloc occurs, res.gid.gid_val must be NULL before the call. Then, the malloc'd memory needs to be free'd. mem_free() just calls free(9), so a NULL pointer argument is fine and a length argument == 0 is ok, since the "len" argument is not used. This bug would have only affected nfs-over-tls and only when rpc.tlsservd(8) is running with the "-u" command line option.
* Add a new "tlscertname" NFS mount option.Rick Macklem2020-12-236-7/+37
| | | | | | | | | | | | | When using NFS-over-TLS, an NFS client can optionally provide an X.509 certificate to the server during the TLS handshake. For some situations, such as different NFS servers or different certificates being mapped to different user credentials on the NFS server, there may be a need for different mounts to provide different certificates. This new mount option called "tlscertname" may be used to specify a non-default certificate be provided. This alernate certificate will be stored in /etc/rpc.tlsclntd in a file with a name based on what is provided by this mount option.
* Fix a potential memory leak in the NFS over TLS handling code.Rick Macklem2020-09-051-0/+2
| | | | | | | | | | | | | | For the TLS case where there is a "user@domain" name specified in the X.509 v3 certificate presented by the client in the otherName component of subjectAltName, a gid list is allocated via mem_alloc(). This needs to be free'd. Otherwise xp_gidp == NULL and free() handles that. (The size argument to mem_free() is not used by FreeBSD, so it can be 0.) This leak would not have occurred for any other case than NFS over TLS with the "user@domain" in the client's certificate. Notes: svn path=/head/; revision=365355
* Remove a duplicate declarationMitchell Horne2020-09-031-2/+0
| | | | | | | | | | This is already declared in sys/file.h, which is included directly. Compiling with GCC9 emits an error. Discussed with: rmacklem Notes: svn path=/head/; revision=365316
* Add TLS support to the kernel RPC.Rick Macklem2020-08-2214-21/+1618
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An internet draft titled "Towards Remote Procedure Call Encryption By Default" describes how TLS is to be used for Sun RPC, with NFS as an intended use case. This patch adds client and server support for this to the kernel RPC, using KERN_TLS and upcalls to daemons for the handshake, peer reset and other non-application data record cases. The upcalls to the daemons use three fields to uniquely identify the TCP connection. They are the time.tv_sec, time.tv_usec of the connection establshment, plus a 64bit sequence number. The time fields avoid problems with re-use of the sequence number after a daemon restart. For the server side, once a Null RPC with AUTH_TLS is received, kernel reception on the socket is blocked and an upcall to the rpctlssd(8) daemon is done to perform the TLS handshake. Upon completion, the completion status of the handshake is stored in xp_tls as flag bits and the reply to the Null RPC is sent. For the client, if CLSET_TLS has been set, a new TCP connection will send the Null RPC with AUTH_TLS to initiate the handshake. The client kernel RPC code will then block kernel I/O on the socket and do an upcall to the rpctlscd(8) daemon to perform the handshake. If the upcall is successful, ct_rcvstate will be maintained to indicate if/when an upcall is being done. If non-application data records are received, the code does an upcall to the appropriate daemon, which will do a SSL_read() of 0 length to handle the record(s). When the socket is being shut down, upcalls are done to the daemons, so that they can perform SSL_shutdown() calls to perform the "peer reset". The rpctlssd(8) and rpctlscd(8) daemons require a patched version of the openssl library and, as such, will not be committed to head at this time. Although the changes done by this patch are fairly numerous, there should be no semantics change to the kernel RPC at this time. A future commit to the NFS code will optionally enable use of TLS for NFS. Notes: svn path=/head/; revision=364475
* Add an argument to newnfs_connect() that indicates use TLS for the connection.Rick Macklem2020-08-111-0/+2
| | | | | | | | | | | | | | | | | | For NFSv4.0, the server creates a server->client TCP connection for callbacks. If the client mount on the server is using TLS, enable TLS for this callback TCP connection. TLS connections from clients will not be supported until the kernel RPC changes are committed. Since this changes the internal ABI between the NFS kernel modules that will require a version bump, delete newnfs_trimtrailing(), which is no longer used. Since LCL_TLSCB is not yet set, these changes should not have any semantic affect at this time. Notes: svn path=/head/; revision=364092
* Fix up a comment added by r362455.Rick Macklem2020-06-211-1/+1
| | | | Notes: svn path=/head/; revision=362457
* Modify the way the client side krpc does soreceive() for TCP.Rick Macklem2020-06-212-95/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch, clnt_vc_soupcall() first does a soreceive() for 4 bytes (the Sun RPC over TCP record mark) and then soreceive(s) for the RPC message. This first soreceive() almost always results in an mbuf allocation, since having the 4byte record mark in a separate mbuf in the socket rcv queue is unlikely. This is somewhat inefficient and rather odd. It also will not work for the ktls rx, since the latter returns a TLS record for each soreceive(). This patch replaces the above with code similar to what the server side of the krpc does for TCP, where it does a soreceive() for as much data as possible and then parses RPC messages out of the received data. A new field of the TCP socket structure called ct_raw is the list of received mbufs that the RPC message(s) are parsed from. I think this results in cleaner code and is needed for support of nfs-over-tls. It also fixes the code for the case where a server sends an RPC message in multiple RPC message fragments. Although this is allowed by RFC5531, no extant NFS server does this. However, it is probably good to fix this in case some future NFS server does do this. Notes: svn path=/head/; revision=362455
* Add the .h file that describes the operations for the rpctls_syscall.Rick Macklem2020-05-311-0/+82
| | | | | | | | This .h file will be used by the nfs-over-tls daemons to do the system call that was added by r361599. Notes: svn path=/head/; revision=361658
* Split XDR into separate kernel module. Make krpc depend on xdr.Gleb Smirnoff2020-04-171-0/+1
| | | | | | | | Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D24408 Notes: svn path=/head/; revision=360036
* Move M_RPC malloc type into XDR. Both RPC and XDR libraries useGleb Smirnoff2020-04-171-2/+0
| | | | | | | | | | | this type, but since RPC depends on XDR (not vice versa) we need it defined in XDR to make the module loadable without RPC. Reviewed by: rmacklem Differential Revision: https://reviews.freebsd.org/D24408 Notes: svn path=/head/; revision=360035
* Change the xid for client side krpc over UDP to a global value.Rick Macklem2020-04-051-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | Without this patch, the xid used for the client side krpc requests over UDP was initialized for each "connection". A "connection" for UDP is rather sketchy and for the kernel NLM a new one is created every 2minutes. A problem with client side interoperability with a Netapp server for the NLM was reported and it is believed to be caused by reuse of the same xid. Although this was never completely diagnosed by the reporter, I could see how the same xid might get reused, since it is initialized to a value based on the TOD clock every two minutes. I suspect initializing the value for every "connection" was inherited from userland library code, where having a global xid was not practical. However, implementing a global "xid" for the kernel rpc is straightforward and will ensure that an xid value is not reused for a long time. This patch does that and is hoped it will fix the Netapp interoperability problem. PR: 245022 Reported by: danny@cs.huji.ac.il MFC after: 2 weeks Notes: svn path=/head/; revision=359643
* Remove obsolete old-freebsd version compat shim.Warner Losh2020-03-011-4/+0
| | | | Notes: svn path=/head/; revision=358509
* Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)Pawel Biernacki2020-02-262-5/+7
| | | | | | | | | | | | | | | | | | | r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718 Notes: svn path=/head/; revision=358333
* Change r355157 to make svc_rpc_gss_lifetime_max a static.Rick Macklem2019-11-281-1/+1
| | | | | | | MFC after: 2 weeks Notes: svn path=/head/; revision=355161
* Add a cap on credential lifetime for Kerberized NFS.Rick Macklem2019-11-281-1/+13
| | | | | | | | | | | | | | | | | | | | | The kernel RPCSEC_GSS code sets the credential (called a client) lifetime to the lifetime of the Kerberos ticket, which is typically several hours. As such, when a user's credentials change such as being added to a new group, it can take several hours for this change to be recognized by the NFS server. This patch adds a sysctl called kern.rpc.gss.lifetime_max which can be set by a sysadmin to put a cap on the time to expire for the credentials, so that a sysadmin can reduce the timeout. It also fixes a bug, where time_uptime is added twice when GSS_C_INDEFINITE is returned for a lifetime. This has no effect in practice, sine Kerberos never does this. Tested by: pen@lysator.liu.se PR: 242132 Submitted by: pen@lysator.liu.se MFC after: 2 weeks Notes: svn path=/head/; revision=355157
* Avoid relying on header pollution from sys/refcount.h.Mark Johnston2019-07-291-0/+1
| | | | | | | | MFC after: 3 days Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=350421