The module panicked at unload with "recursing but non-recursive rw".
There is a comment that "Unloading of the kgssapi module is not
currently supported" and the MOD_UNLOAD case falls through to returning
EOPNOTSUPP anyway.  Just #if 0 the code in the unload path, leaving it
as a hint in case someone implements unload support later on.

PR:		291249
Reviewed by:	rmacklem
Fixes: ad704a34bc2c ("Use syscall_helper_register(9) rather than syscall_register().")
Sponsored by:	The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53949

(cherry picked from commit 6901376f59b870ddbb0d922e3455a388333cd460)
(cherry picked from commit ab4f4f4efaac85bbf235e60f2ced4876a9e916f2)

- Instead of using CRYPTO_F_DONE to decide whether a request has
  completed, use a custom protocol of setting crp_opaque = NULL in the
  callback and checking that instead.  CRYPTO_F_DONE is set independent
  of whether an error occurred, but for transient errors signaled by
  EAGAIN, we want to simply retry the request.
- Clear CRYPTO_F_DONE before retrying the request.
- Panic if the request truly failed, as we currently have no way to
  pass hard errors back up.

Reviewed by:	jhb
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D50238

(cherry picked from commit 04421fda140b92eb0d22bc4c0f81b6de05f21225)

During recent testing related to the IETF NFSv4 Bakeathon, it was
discovered that Kerberized NFSv4.1/4.2 mounts to pNFS servers
(sec=krb5[ip],pnfs mount options) was broken.
The FreeBSD client was using the "service principal" for
the MDS to try and establish a rpcsec_gss credential for a DS,
which is incorrect. (A "service principal" looks like
"nfs@<fqdn-of-server>" and the <fqdn-of-server> for the DS is not
the same as the MDS for most pNFS servers.)

To fix this, the rpcsec_gss code needs to be able to do a
reverse DNS lookup of the DS's IP address.  A new kgssapi upcall
to the gssd(8) daemon is added by this patch to do the reverse DNS
along with a new rpcsec_gss function to generate the "service
principal".

A separate patch to the gssd(8) will be committed, so that this
patch will fix the problem.  Without the gssd(8) patch, the new
upcall fails and current/incorrect behaviour remains.

This bug only affects the rare case of a Kerberized (sec=krb5[ip],pnfs)
mount using pNFS.

This patch changes the internal KAPI between the kgssapi and
nfscl modules, but since I did a version bump a few days ago,
I will not do one this time.

(cherry picked from commit dd7d42a1fae5a4879b62689a165238082421f343)

A future commit needs a new upcall function that can do reverse
DNS in order to generate a "service principal".
This patch adds the file.

(cherry picked from commit 428879dc9110240ad0940c7ac8cd69bcaf6e686e)

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Remove /^/[*/]\s*\$FreeBSD\$.*\n/

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with:		pfg
MFC After:		3 days
Sponsored by:		Netflix

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