No functional change.

This is a cleanup to simplify a patch for PR 260116.

PR:		260116
MFC after:	3 days

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 37351133 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

MFC after:	2 weeks

The implemenation differs from others Linuxulators.
For unwinders Linux ucontext_t is stored, however native machine context
is used to store/restore process state to avoid code duplication.

As DWARF Aarch64 does not define a register number for PC and provides no
direct way to encode the PC of the previous frame, CFI cannot describe a
signal trampoline frame. So, modified the vdso linker script to discard
unused sections.

Extensions are not implemented.

MFC after:		2 weeks

MFC after:		2 weeks

The Linux exports __kernel_sigreturn and __kernel_rt_sigreturn from the
vdso. Modern glibc's sigaction sets the sa_restorer field of sigaction
to the corresponding vdso __sigreturn, and sets the SA_RESTORER.
Our signal trampolines uses the FreeBSD-way to call a signal handler,
so does not use the sigaction's sa_restorer.

However, as glibc's runtime linker depends on the existment of the vdso
__sigreturn symbols, for all Linuxulators was added separate trampolines
named __sigcode with DWARF anotations and left separate __sigreturn
methods, which are exported.

MFC after:		2 weeks

To reduce sendsig code difference and to avoid confusing me,
rename sf_sc to sf_uc to match the content.

MFC after:		2 weeks

Rework the defintion of struct siginfo so that the array padding
struct siginfo to SI_MAX_SIZE can be placed in a union along side of the
rest of the struct siginfo members.  The result is that we no longer need
the __ARCH_SI_PREAMBLE_SIZE or SI_PAD_SIZE definitions.

Move struct siginfo definition under /compat/linux to reduce MD part.
To avoid headers polution include linux_siginfo.h in the MD linux.h

MFC after:		2 weeks

The signal trampoine-related definitions are used only in the MD part
of code, wherefore moved from everywhere used linux.h to separate MD
headers.

MFC after:		2 weeks

This is the first stage of a signal trampolines refactoring.

From trampolines retired emulation of the 'call' instruction, which is
replaced by direct call of a signal handler. The signal handler address
is in the register.

The previous trampoline implemenatation used semi-Linux-way to call
a signal handler via the 'jmp' instruction. Wherefore the trampoline
emulated a 'call' instruction to into the stack the return address for
signal handler's 'ret' instruction.  Wherefore handmade DWARD annotations
was used.

While here rephrased and removed excessive comments.

MFC after:		2 weeks

Both uc_flags and uc_link are zeroed above. On amd64 and i386 the
uc_link field is not used at all. The UC_FP_XSTATE bit should be set
in the uc_flags if OS xsave knob is turned on (and xsave is implemented).

MFC after:		2 weeks

It's mostly modeled like the Linux does.

Differential revision:	https://reviews.freebsd.org/D35154
MFC after:		2 weeks

MFC after:	3 days

Ensure that a HB can be sent faster than a HB.Interval when performing
path verification of a reachable peer address.

Thanks to Alexander Funke for finding the issue and proposing a fix.

MFC after:	3 days

When sending path confirmation heartbeats, do not take HB.interval
into account when the path is still reachable.

Thanks to Alexander Funke for finding the issue and suggesting a fix.

MFC after:	3 days

No functional change intended.

MFC after:	3 days

Since 0b3178a4 we have added '-d' to the link command line for
kernel modules, so if any unexpected common symbols turn up (even though
we use -fno-common in CFLAGS), storage will be allocated in in the
module itself.

However, with lld this option did not have any effect since ~2017, and
as of lld 14 it warns: "-d, -dc, -dp, and --[no-]define-common will be
removed. See https://github.com/llvm/llvm-project/issues/53660"

Add a linker type and version check, to avoid adding the option for lld
14 and later.

Reported by:	bz
MFC after:	2 weeks

Without this patch, the MSG_TLSAPPDATA flag would cause
soreceive_generic() to return ENXIO for any non-application
data record in a TLS receive stream.

This works ok for TLS1.2, since Alert records appear to be
the only non-application data records received.
However, for TLS1.3, there can be post-handshake handshake
records, such as NewSessionKey sent to the client from the
server. These handshake records cannot be handled by the
upcall which does an SSL_read() with length == 0.

It appears that the client can simply throw away these
NewSessionKey records, but to do so, it needs to receive
them within the kernel.

This patch modifies the semantics of MSG_TLSAPPDATA slightly,
so that it only applies to Alert records and not Handshake
records. It is needed to allow the krpc to work with KTLS1.3.

Reviewed by:	hselasky
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D35170

Previously we expected the DIOCSKERNELDUMP ioctl to return ENXIO if the
interface was down, but it does not actually do this. Grab the link
status using getifaddrs(3) instead, and downgrade this case from an
error to a warning; the user might bring the link back up at a later
time.

Reviewed by:	cem
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D35196

If the interface does not support debugnet(4) we should bail early,
rather than having the user find this out at the time of the panic.
dumpon(8) already expects this return value and will print a helpful
error message.

Reviewed by:	cem, markj
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D35180

We may call debugnet_free() before g_debugnet_pcb_inuse is true,
specifically in the cases where the interface is down or does not
support debugnet. pcb->dp_drv_input is used to hold the real driver
if_input callback while debugnet is in use, so we can check the status
of this field in the assertion.

This can be triggered trivially by trying to configure netdump on an
unsupported interface at the ddb prompt.

Initializing the dp_drv_input field to NULL explicitly is not necessary
but helps display the intent.

PR:		263929
Reported by:	Martin Filla <freebsd@sysctl.cz>
Reviewed by:	cem, markj
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D35179

Remove bogus BUGS note about timeout limit to 24 hours, that's not true
since callouting project import.

Reviewed by:		mav
Differential revision:	https://reviews.freebsd.org/D35206
MFC after:		2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.3-0-g1f9140064dfb.

PR:		261742
MFC after:	2 weeks

Merge commit 44cdca37c01a from llvm git (by Arthur O'Dwyer):

  [libc++] Define `namespace views` in its own detail header.

  Discovered in the comments on D118748: we would like this namespace
  to exist anytime Ranges exists, regardless of whether concepts syntax
  is supported. Also, we'd like to fully granularize the <ranges> header,
  which means not putting any loose declarations at the top level.

  Differential Revision: https://reviews.llvm.org/D118809

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-2-g3f43d803382d.

PR:		261742
MFC after:	2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc4-2-gadd3ab7f4c8a.

PR:		261742
MFC after:	2 weeks

Merge commit 7ab1ab0db401 from llvm git (by Dimitry Andric):

  [libc++] Make __dir_stream visibility declaration consistent

  The class `__dir_stream` is currently declared in two places: as a
  top-level forward declaration in `directory_iterator.h`, and as a friend
  declaration in class `directory_entry`, in `directory_entry.h`.

  The former has a `_LIBCPP_HIDDEN` attribute, but the latter does not,
  causing the Firefox build to complain about the visibility not matching
  the previous declaration. This is because Firefox plays games with
  pushing and popping visibility.

  Work around this by making both `__dir_stream` declarations consistently
  use `_LIBCPP_HIDDEN`.

  Reviewed By: ldionne, philnik, #libc

  Differential Revision: https://reviews.llvm.org/D121639

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc2-12-g09546e1b5103.

PR:		261742
MFC after:	2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc1-74-g4dc3cb8e3255.

PR:		261742
MFC after:	2 weeks

Merge commit 027c16bef4b7 from llvm git (by Nick Desaulniers):

  [X86ISelLowering] permit BlockAddressSDNode "i" constraints for PIC

  When building 32b x86 code as PIC, the existing handling of "i"
  constraints is conservative since generally we have to go through the
  GOT to find references to functions.

  But generally, BlockAddresses from C code refer to the Function in the
  current TU.  Permit BlockAddresses to be used with the "i" constraint
  for those cases.

  I regressed this in
  commit 4edb9983cb8c ("[SelectionDAG] treat X constrained labels as i for asm")

  Fixes: https://github.com/llvm/llvm-project/issues/53868

  Reviewed By: efriedma, MaskRay

  Differential Revision: https://reviews.llvm.org/D119905

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-18315-g190be5457c90.

PR:		261742
MFC after:	2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-18294-gdb01b123d012, the last commit before
the upstream release/14.x branch was created.

PR:		261742
MFC after:	2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-17616-g024a1fab5c35.

PR:		261742
MFC after:	2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-13186-g0c553cc1af2e.

PR:		261742
MFC after:	2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-11187-g222442ec2d71.

PR:		261742
MFC after:	2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10223-g401b76fdf2b3.

PR:		261742
MFC after:	2 weeks

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10186-gff7f2cfa959b.

PR:		261742
MFC after:	2 weeks

Per jamie@ rpr can be NULL if the jail is created with sysvsem=disable.
But at least it doesn't appear to be fatal, since rpr is never dereferenced
but is only compared to other prison pointers.

Reviewed by:		jamie
Differential revision:	https://reviews.freebsd.org/D35198
MFC after:		2 weeks

MFC after:	2 weeks