The "void *stuff" (also called fstuff and dstuff) argument
was used by the Mac OSX port.  For FreeBSD, this argument
is always NULL, so remove it to clean up the code.

This commit gets rid of "stuff" for assorted functions
defined in nfs_clrpcops.c and called in nfs_clvnops.c.
Future commits will do the same for other functions.

This commit should not result in a semantics change.

libpmc already returns an end address that is after the end of the
last instruction of a function (on both amd64 and arm64) as the end
address written to the annotate map file is computed as the start
address of the symbol plus the size.

Adding one could result in a curious failure where an entire
function's contents in assembly was reduced instead to only the first
instruction.  The reason is that when the end instruction is bumped by
one, objdump -d can append the first instruction of the next function
in its output.  However, since pmcannotate concatenates all of the
objdump -d output from various functions into a single file which it
then searches to find the assembly for a given file, if this
additional trailer was earlier in the file than the full function, the
trailer was chosen to represent the entire function resulting in the
truncated listing of the function.

Sponsored by:	University of Cambridge, Google, Inc.
Differential Revision:	https://reviews.freebsd.org/D35399

Commit acfb506b replaced an exit 0 when using -V with a return
instead.  FreeBSD's sh treats a return outside of a function like
exit, but this is a non-portable extension.  Other Bourne shells only
permit return to be used within a function and continue execution
(possibly with a warning).

To fix, don't reuse VARS_ONLY (which is intended to be set by other
scripts before sourcing newvers.sh directly) and instead use a new
variable (VARS_ONLY_EXIT) to restore the use of exit for the
non-sourced case.

Reviewed by:	emaste
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D35481

'@' is not a valid character in symbol names and can sometimes appear
in path names.

Reviewed by:	imp, markj
Obtained from:	CheriBSD
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D35480

ntpd does not always gracefully handle clock steps during resume.
This is probably most useful in conjunction with
ntpd_sync_on_start=YES which will work around any clock skew while
suspended.

Reviewed by:	manu
Differential Revision:	https://reviews.freebsd.org/D35479

If ktls.require_ifnet is set to true, then check the TLS offload mode
for tests sending and receiving records and skip the test if the
offload mode is not ifnet mode.

This can be used along with ktls.host to run KTLS tests against a NIC
supporting ifnet TLS and verify that expected cipher suites and
directions used ifnet TLS rather than software TLS.  Receive tests may
result in a false positive as receive ifnet TLS can use software as a
fallback.

Reviewed by:	markj
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D35427

Previously ktls tests always executed over a local socket pair.
ktls.host can be set to a host to connect to with a single socket
instead.  The remote end is expected to echo back any data received
(such as the echo service).  The port can be set with ktls.port which
defaults to "echo".

This is primarily useful to permit testing NIC TLS offload use cases
where the traffic needs to transit the NIC.

Note that the variables must be set via
'kyua -v test_suites.FreeBSD.ktls.host=host'.

Reviewed by:	markj
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D35426

Reviewed by:	markj
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D35425

'command' is too generic for something specific to the kernel debugger;
change this so it is less likely to collide with local variable names.
Also rename struct command_table to struct db_command_table.

Reviewed by:	markj
MFC after:	1 week
Sponsored by:	Juniper Networks, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D35367

They are not loadable otherwise.

Reviewed by:	emaste
MFC after:	1 week
Sponsored by:	Juniper Networks, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D35369

The pointer to the mount values may be null if an error occurred while
copying them in, so fix the assertion condition to reflect that
possibility.

While here, move some initialization code into the error == 0 block.  No
functional change intended.

Reported by:	syzkaller
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation

... rather than setting and clearing flags inline.  No functional change
intended.

Reviewed by:	alc, kib
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D35469

print_cmsg() was assuming that the control message chain is well-formed,
but that isn't necessarily the case for sendmsg(2).  In particular, if
cmsg_len is zero, print_cmsg() will loop forever.  Check for truncated
headers and try to recover if possible.

Reviewed by:	tuexen
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D35476

See also commit 71a1539e.

Reported by:	syzbot+9b461b6a07a83cc10daa@syzkaller.appspotmail.com
Reported by:	syzbot+b6ce0aec16f5fdab3282@syzkaller.appspotmail.com
Reviewed by:	glebius
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D35472

Suppose a thread tries to read from an empty pipe.  pipe_read() does the
following:

1. pipelock(), possibly sleeping
2. check for buffered data
3. pipeunlock()
4. set PIPE_WANTR and sleep
5. goto 1

pipelock() is an open-coded mutex; if a thread blocks in pipelock(), it
sleeps until the lock holder calls pipeunlock().

Both sleeps use the same wait channel.  So if there are multiple threads
in pipe_read(), a thread T1 in step 3 can wake up a thread T2 sleeping
in step 4.  Then T1 goes to sleep in step 4, and T2 acquires and
releases the pipelock, waking up T1 again.  This can go on indefinitely,
livelocking the process (and potentially starving a would-be writer).

Fix the problem by using a separate wait channel for pipelock().

Reported by:	Paul Floyd <paulf2718@gmail.com>
Reviewed by:	mjg, kib
PR:		264441
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D35415

bapt@ had discovered a noticeable boot improvement without the sleep.
Without the sleep does not affect warm or cold boot however a
service netif restart may cause dhclient to spend a few extra seconds
to rerequest the DHCP request.

Reported by:	bapt
Reviewed by:	bapt
MFC after:	2 months
Differential Revision:	https://reviews.freebsd.org/D35457

They are no longer needed, but were likely missed simply because they
don't show up in a grep for 'mips'.

Reviewed by:	emaste
Differential Revision:	https://reviews.freebsd.org/D35475

null_nodeget() needs a valid mount point data, otherwise we might
race and dereference NULL.

Using MBF_NOWAIT makes non-forced unmount non-transparent for
vn_fullpath() over nullfs, but we make no guarantee that fullpath
calculation succeeds anyway.

Reported and tested by:	pho
Reviewed by:	jah
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D35477

Reverse the order of the search for a free space in lowermatch, to
make it a first-fit search. Iommu_gas_match_one always allocates from
the beginning of the free gap discovered from searching the tree, so
the current code isn't really allocating in a reverse first-fit
anyway, and making the search first-fit reduces the number of iommu
page table pages that are used.

Reported by:	alc
Reviewed by:	alc, kib
MFC after:	3 weeks
Differential Revision:	https://reviews.freebsd.org/D35458

I've found couple cases when CTL_FLAG_SENT_2OTHER_SC flags were not
cleared on commands return from active node or the send failure.  It
created races when ctl_failover_lun() call before ctl_process_done()
could cause second ctl_done() and ctl_process_done() calls, causing
all sorts of problems.

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

Chase 4493a13e by updating static
assertions of struct proc.

This patch removes warnings messages like the following added in ACPICA
20220331:

    ACPI Warning: Firmware issue: Excessive sleep time (0xxx ms > 10 ms)
    in ACPI Control Method (20220331/exsystem-347)

Note the original author of this patch wants to back it out:

https://github.com/acpica/acpica/pull/780

The "void *stuff" (also called fstuff and dstuff) argument
was used by the Mac OSX port.  For FreeBSD, this argument
is always NULL, so remove it to clean up the code.

This commit gets rid of "stuff" for assorted functions
defined in nfs_clrpcops.c and called in nfs_clvnops.c.
Future commits will do the same for other functions.

This commit should not result in a semantics change.

Add a target to ensure the presence of /usr/include/i386
before we try to install files.  In the buildworld/installworld path
it gets created different ways, but for distribute (used in releases)
we need it in the subdir.

(Creating of this the x86, pc, powerpc directories is far too complex.
We should look for ways to simplify it.)

Reported by:	lwhsu
Fixes:		a09ea2bb

This is racy because curproc process lock is not used, but allows the
process to exit faster.  It is userspace issue to create such race
anyway, and not fullfilling the guarantee that all reaper descendants
are signalled should be fine.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

We drop proctree_lock, which allows the process to exit while memoized
in the list to proceed.

Reported and tested by:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

Recorded reaper might loose its reaper status, so we should not assert
it, but check and avoid signalling if this happens.

Reported and tested by:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 week
Differential revision:	https://reviews.freebsd.org/D35310

The failure means that the process does single-threading itself, which
makes our action not needed.

Reported and tested by:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

If we try to single-thread a process which thread entered
procctl(REAP_KILL_SUBTREE), and sleeping waiting for us unlocking
stop_all_proc_blocker, we must be able to finish single-threading.  This
requires the sleep to be interruptible.

Reported and tested by:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 week
Differential revision:	https://reviews.freebsd.org/D35310

markj wrote:
tdsendsignal() may unsuspend a target thread. I think there is at least
one bug there: suppose thread T is suspended in
thread_single(SINGLE_ALLPROC) when trying to kill another process with
REAP_KILL. Suppose a different thread sends SIGKILL to T->td_proc. Then,
tdsendsignal() calls thread_unsuspend(T, T->td_proc). thread_unsuspend()
incorrectly decrements T->td_proc->p_suspcount to -1.

Later, when T->td_proc exits, it will wait forever in
thread_single(SINGLE_EXIT) since T->td_proc->p_suspcount never reaches 1.

Since the thread suspension is bounded by time needed to do
thread_single(), skipping the thread_unsuspend_one() call there should
not affect signal delivery if this thread is selected as target.

Reported by:	markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

Reviewed by:	markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

Since both self single-threading and remote single-threading rely on
suspending the thread doing thread_single(), it cannot be mixed: thread
doing thread_suspend_switch() might be subject to thread_suspend_one()
and vice versa.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

suspended for SINGLE_ALLPROC mode.  There is no need to check for
boundary state.  It is only required to see that the suspension comes
from the ALLPROC mode.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

to avoid ALLPROC mode to try to race with any other single-threading
mode.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

Places that will wait for curproc->p_singlethr to become zero (in the
next commit, the counter of number of external single-threading is
to be introduced), must wait for it interruptible, otherwise we
deadlock.  On the other hand, a signal delivered during this window,
if directed to the waiting thread, would cause the wait loop to become
a busy loop.

Since we are exiting, it is safe to ignore the signals.

Reviewed by:	markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

before the process itself does thread_single(SINGLE_EXIT).  We cannot
single-thread such process in ALLPROC (external) mode, and properly
detect and report the failure to do so due to the process becoming
zombie is easier to prevent than handle.

In collaboration with:	pho
Reviewed by:	markj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D35310

If installing from the DVD, mount its packages in the chroot at
/dist/packages.  That way they'll be accessible to an install script.

MFC after:	2 weeks
Sponsored by:	Axcient
Reviewed by:	gjb
Differential Revision: https://reviews.freebsd.org/D35330