Requested by:	kib

Fixes:		bd7630ef ia32: Sync signal context type names with i386.

IVs are not the size of keys as a general case.  Most often they are
the size of a single block.

Reviewed by:	imp
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33885

- Use AES_XTS_IV_LEN instead of the key length as the IV length.
- Use G_ELI_IVKEYLEN as the size of the zeroed iv[] array in
  g_eli_crypto_cipher() to match geli_io().

PR:		261172
Reported by:	Malcolm Matalka <mmatalka@gmail.com>, mikael
Reviewed by:	markj
Sponsored by:	FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33884

Requested by:	kib
Reviewed by:	brooks, imp, kib
Sponsored by:	The University of Cambridge, Google Inc.
Differential Revision:	https://reviews.freebsd.org/D33886

- Use ia32_freebsd4_* instead of ia32_*4.
- Use ia32_o* instead of ia32_*3.

Reviewed by:	brooks, imp, kib
Sponsored by:	The University of Cambridge, Google Inc.
Differential Revision:	https://reviews.freebsd.org/D33882

Reviewed by:	brooks, imp, kib
Sponsored by:	The University of Cambridge, Google Inc.
Differential Revision:	https://reviews.freebsd.org/D33881

This matches the recent renaming of struct freebsd4_ucontext.

Reviewed by:	brooks, imp, kib
Sponsored by:	The University of Cambridge, Google Inc.
Differential Revision:	https://reviews.freebsd.org/D33880

Differential review:	https://reviews.freebsd.org/D33875
Approved by:	dim, imp

The ACPI spec describes the FADT->Century field as:

    The RTC CMOS RAM index to the century of data value (hundred and
    thousand year decimals).  If this field contains a zero, then the
    RTC centenary feature is not supported.  If this field has a non-zero
    value, then this field contains an index into RTC RAM space that
    OSPM can use to program the centenary field.

Use this field to decide whether to program the CENTURY register
of the CMOS RTC device.

Reviewed by:	akumar3@isilon.com, dab, vangyzen
MFC after:	1 week
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D33667

MFC after:	1 week
Sponsored by:	Dell EMC Isilon

GNU's libssp installed this (in addition to libssp_nonshared.a), but
the libc-based libssp does not.

Reviewed by:	kevans, emaste
Fixes:		cd0d51ba Provide libssp based on libc
Sponsored by:	The University of Cambridge, Google Inc.
Differential Revision:	https://reviews.freebsd.org/D33852

Reviewed by:	imp, emaste
Fixes:		eb61f7bd Stop building libl and liby
Sponsored by:	The University of Cambridge, Google Inc.
Differential Revision:	https://reviews.freebsd.org/D33851

Reviewed by:	emaste
Sponsored by:	The University of Cambridge, Google Inc.
Differential Revision:	https://reviews.freebsd.org/D33850

If the last matching device entry partially matched in camperiphunit,
but then hit a continue case, we'd mistakenly think we had a match on
that entry. This lead to a number of problems downstream (usually a
belief that we had a duplicate wiring hint because unit = 0 is the
default). Fix this by using a for loop that does the assignment before
the loop termination test.

Sponsored by:		Netflix
Reviewed by:		jhb
Differential Revision:	https://reviews.freebsd.org/D33873

This tool can be used to detect install conflicts (ports/packages that
conflict with each other because of identically named files).

MFC after:	3 days

Weird side of SES specification is that some bits have different
meaning or semantics in status and control pages.  This patch fixes
non-zero writes into reserved fields, that caused errors on some
enclosures when trying to control locate/fault LEDs, keeping other
bits unchanged.

MFC after:	2 weeks
Sposonred by:	iXsystems, Inc.

LRO was willing to merge ACK and non-ACK packets together.  This
can cause incorrect th_ack values to be reported up the stack.
While non-ACKs are quite unlikely to appear in practice, LRO's
behaviour is against the spec.  Make LRO unwilling to merge
packets with different TH_ACK flag values in order to fix the
issue.

Found by: Sysunit test
Differential Revision:	https://reviews.freebsd.org/D33775
Reviewed by: rrs

To check if it needed to regenerate a packet's header before
sending it up the stack, LRO was checking if more than one payload
had been merged into the packet.  This failed in the case where
a single payload was merged with one or more pure ACKs.  This
results in lost ACKs.

Fix this by precisely tracking whether header regeneration is
required instead of using an incorrect heuristic.

Found with: Sysunit test
Differential Revision:	https://reviews.freebsd.org/D33774
Reviewed by: rrs

The old bogus Xen versions that would deliver a GPF when writing to
the LAPIC MSR are likely retired, so it's safe to enable x2APIC
unconditionally now if available.

Tested by: avg
Reviewed by: kib
Sponsored by: Citrix Systems R&D
Differential revision: https://reviews.freebsd.org/D33877

If the UMA zones are not freed, we get warnings about re-using the
sysctl variables associated with the UMA zones, and we're leaking
the other memory associated with the zone structures.  e.g.:

sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.size)!
sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.flags)!
sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.bucket_size)!
sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.bucket_size_max)!
sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.keg.name)!
sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.keg.rsize)!
sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.keg.ppera)!
sysctl_warn_reuse: can't re-use a leaf (vm.uma.pass44.keg.ipers)!

Also, correctly clear the PASS_FLAG_ZONE_INPROG flag in
passcreatezone().  The way it was previously done, it would have
had set the flag and cleared all other flags that were set at
that point.

MFC after:	1 week
Sponsored by:	Spectra Logic

When running as a Xen guest it's easier to use an hypercall in order
to do power management operations (power off, power cycle). Do this
for all supported guest types (HVM and PVH). Note that for HVM the
power operation could also be done using ACPI, but there's no reason
to differentiate between PVH and HVM.

While there fix the shutdown handler to properly differentiate between
power cycle and power off requests.

Reported by: Freddy DISSAUX
MFC: 1 week
Sponsored by: Citrix Systems R&D

This is already present as WITHOUT_MODULES

This reverts commit 8c0c5bdf.

Reported by:	jrtc27

It's sometimes easier to exclude some modules rather than listing all
possibly needed ones with MODULES_OVERRIDE.
So for this add MODULES_EXCLUDE which do exactly as one would guess, excludes
some modules from the build/install.

For example if one wants to exclude all modules which are only present in the
GENERIC config on amd64 :
export MODULES_EXCLUDE=$(grep -E '^device' sys/amd64/conf/GENERIC | awk '{print $2}' | tr '\n' ' ')

MFC after:	2 weeks
Sponsored by:	Beckhoff Automation GmbH & Co. KG
Differential Revision:	https://reviews.freebsd.org/D33443

Mark Milliard has detected a case of undefined behavior with the LLVM
UBSAN. The mandoc program called qsort with a==NULL and n==0, which is
allowed by the POSIX standard. The qsort() in FreeBSD did not attempt
to perform any accesses using the passed pointer for n==0, but it did
add an offset to the pointer value, which is undefined behavior in
case of a NULL pointer. This operation has no adverse effects on any
achitecture supported by FreeBSD, but could be caught in more strict
environments.

After some discussion in the freebsd-current mail list, it was
concluded that the case of a==NULL and n!=0 should still be caught by
UBSAN (or cause a program abort due to an illegal access) in order to
not hide errors in programs incorrectly invoking qsort().

Only the the case of a==NULL and n==0 should be fixed to not perform
the undefined operation on a NULL pointer.

This commit makes qsort() exit before reaching the point of
potentially undefined behvior for the case n==0, but does not test
the value of a, since the result will not depend on whether this
pointer is NULL or an actual pointer to an array if n==0.

The issue found by Mark Milliard in the whatis command has been
reported to the upstream (OpenBSD) and has already been patched
there.

MFC after:	1 week

- In mana_create_txq(), if test fails we must free some resources
  as in all the other handling paths of this function.
- In mana_gd_read_cqe(), add warning log in case of CQE read
  overflow, instead of failing silently.
- Fix error handling in mana_create_rxq() when
  cq->gdma_id >= gc->max_num_cqs.
- In mana_init_port(), use the correct port index rather than 0.
- In mana_hwc_create_wq(), If allocating the DMA buffer fails,
  mana_hwc_destroy_wq was called without previously storing the
  pointer to the queue. In order to avoid leaking the pointer to
  the queue, store it as soon as it is allocated.

MFC after:	2 weeks
Sponsored by:	Microsoft

Currently when the HWC creation fails, the error handling is flawed,
e.g. if mana_hwc_create_channel() -> mana_hwc_establish_channel() fails,
the resources acquired in mana_hwc_init_queues() is not released.

Enhance mana_hwc_destroy_channel() to do the proper cleanup work and
call it accordingly.

MFC after:	2 weeks
Sponsored by:	Microsoft

Signed-off-by: Eric Joyner <erj@FreeBSD.org>

Sponsored by:	Intel Corporation

Missed issues in truss on at least armv7 and powerpcspe need to be
resolved before recommit.

This reverts commit 3889fb8a.
This reverts commit 1544e0f5.

This more clearly differentiates system call arguments from integer
registers and return values. On current architectures it has no effect,
but on architectures where pointers are not integers (CHERI) and may
not even share registers (CHERI-MIPS) it is necessiary to differentiate
between system call arguments (syscallarg_t) and integer register values
(register_t).

Obtained from:	CheriBSD

Reviewed by:	imp, kib
Differential Revision:	https://reviews.freebsd.org/D33780

Fix comment documenting checksum block in ip_nat.c. Fastforward doesn't
perform checksum.

MFC after:	1 week

Don't assume checksums will be calculated later in fastforward.

MFC after:	1 week

MFC after:	3 days

Correct the parameters descriptions for ipf_fix_outcksum and
ipf_fix_incksum.

MFC after:	3 days

Remove superfluous inline for function defined as extrn.

MFC after:	3 days

Combine two else ifs using an or.

MFC after:	3 days