cb130596 kp Sept. 23, 2021, 7:56 p.m.
We can't copyout() while holding a lock, in case it triggers a page
Release the lock before copyout, which is safe because we've already
copied all the data into the nvlist.

PR:		258601
Reviewed by:	mjg
MFC after:	1 week
Sponsored by:	Modirum MDPay
Differential Revision:	https://reviews.freebsd.org/D32076
d5ad2f2a kbowling Sept. 23, 2021, 7:41 p.m.
This patch is for the following updates to the K1 configurations:
Tx idle period for entering K1 should be 128 ns.
Minimum Tx idle period in K1 should be 256 ns.

Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>

PR:		258153
Reviewed by:	erj
Tested by:	iron.udjin@gmail.com
Approved by:	imp
Obtained from:	DPDK (6f934fa24dfd437c90ead96bc7598ee77a117ede)
MFC after:	1 week
f555b39e kevans Sept. 23, 2021, 7:13 p.m.
From jilles: POSIX requires that a script set `OPTIND=1` before using
different sets of parameters with `getopts`, or the results will be

The specific problem observed here is that we would execute `man -f` or
`man -k` without cleaning up state from man_parse_args()' `getopts`
loop.  FreeBSD's /bin/sh seems to reset OPTIND to 1 after we hit the
second getopts loop, rendering the following shift harmless; other
/bin/sh implementations will leave it at what we came into the loop at
(e.g., bash as /bin/sh), shifting off any keywords that we had.

Input from:	jilles
Reviewed by:	allanjude, bapt, imp
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D32063
ef50d5fb mav Sept. 23, 2021, 6:31 p.m.
Depending on hardware, NUMA nodes may match last level caches, or
they may be above them (AMD Zen 2/3) or below (Intel Xeon w/ SNC).
This information is provided by ACPI instead of CPUID, and it is
provided for each CPU individually instead of mask widths, but
this code should be able to properly handle all the above cases.

This change should immediately allow idle stealing in sched_ule(4)
to prefer load from NUMA-local CPUs to remote ones when the node
does not match LLC.  Later we may think of how to better handle it
on sched_pickcpu() side.

MFC after:	1 month
1ca931a5 rrs Sept. 23, 2021, 3:43 p.m.
The compressed ack path of rack is not following proper procedures in updating
the peers window. It should be checking the seq and ack values before updating and
instead it is blindly updating the values. This could in theory get the wrong window
in the connection for some length of time.

Reviewed by: tuexen
Sponsored by: Netflix Inc.
Differential Revision: https://reviews.freebsd.org/D32082
fd69939e rrs Sept. 23, 2021, 2:54 p.m.
In extensive testing in NF we have found two issues inside
the rack stack.

1) An incorrect offset is being generated by the fast send path when a fast send is initiated on
   the end of the socket buffer and before the fast send runs, the sb_compress macro adds data to the trailing socket.
   This fools the fast send code into thinking the sb offset changed and it miscalculates a "updated offset".
   It should only do that when the mbuf in question got smaller.. i.e. an ack was processed. This can lead to
   a panic deref'ing a NULL mbuf if that packet is ever retransmitted. At the best case it leads to invalid data being
   sent to the client which usually terminates the connection. The fix is to have the proper logic (that is in the rsm fast path)
   to make sure we only update the offset when the mbuf shrinks.
2) The other issue is more bothersome. The timestamp check in rack needs to use the msec timestamp when
   comparing the timestamp echo to now. It was using a microsecond timestamp which ends up giving error
   prone results but causes only small harm in trying to identify which send to use in RTT calculations if its a retransmit.

Reviewed by: tuexen
Sponsored by: Netflix Inc.
Differential Revision: https://reviews.freebsd.org/D32062
dbc7ca59 emaste Sept. 23, 2021, 1:51 p.m.
PR:		248628
Reported by:	oleg
Reviewed by:	cem, oleg (both earlier)
Fixes:		ee97b2336aa4 ("Speed up vt(4) by keeping...")
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D32059
414499b3 tuexen Sept. 23, 2021, 12:16 p.m.
No functional change intended.

MFC after:	1 week
0b92a7fe wma Sept. 23, 2021, 8:57 a.m.
The error returned when a marker message can not be emitted on a port is not handled.

This cause the lacp to block all emissions until the timeout of 3 seconds is reached.

To fix this issue, I just clear the LACP_PORT_MARK flag when the packet could not be emitted.

Differential revision:	https://reviews.freebsd.org/D30467
Obtained from:		Stormshield
492bf4fd wma Sept. 23, 2021, 8:53 a.m.
Calling veriexec -i locked return the state of loaded and vice-versa.

Differential revision:	https://reviews.freebsd.org/D30952
Reviewed by:		sjg,imp
Obtained from:		Stromshield
d2c23317 wma Sept. 23, 2021, 8:43 a.m.
Add -o verify to sh to make it use O_VERIFY when
sourcing scripts and reading profiles.

Useful in conjunction with mac_veriexec to help protect at
least some parts of the boot sequence, e.g., /etc/rc*.

Differential revision:	https://reviews.freebsd.org/D30464
Reviewed by:		jilles, sjg
Obtained from:		Stormshield
90f6610b hselasky Sept. 23, 2021, 7:49 a.m.
Submitted by:	gljennjohn@gmail.com
Differential Revision:	https://reviews.freebsd.org/D31636
Sponsored by:	NVIDIA Networking
5e79bba5 kevans Sept. 23, 2021, 6:03 a.m.
Previously, we were collecting at a base rate of:

64 bits x 32 pools x 10 Hz = 2.5 kB/s

This change drops it to closer to 64-ish bits per pool per second, to
work a little better with entropy providers in virtualized environments
without compromising the security goals of Fortuna.

Reviewed by:	#csprng (cem, delphij, markm)
Differential Revision:	https://reviews.freebsd.org/D32021
6895cade kevans Sept. 23, 2021, 6:03 a.m.
Refer to discussion in PR 230808 for a less incomplete discussion, but
the gist of this change is that we currently collect orders of magnitude
more entropy than we need.

The excess comes from bytes being read out of /dev/*random.  The default
rate at which we collect entropy without the read_rate increase is
already more than we need to recover from a compromise of an internal

Reviewed by:	#csprng (cem, delphij, markm)
Differential Revision:	https://reviews.freebsd.org/D32021
7bc13692 wma Sept. 23, 2021, 5:15 a.m.
Differential revision:	https://reviews.freebsd.org/D32025

Avoid using atomics as it_wait is guarded by td_lock.

Report threshold calculation is done only if at least one PMC hook
is installed

* avoid unnecessary branching (if frame != null ...)
  condition on the top of them, which should hint
  the core not to execute speculatively anything
  which us underneath;
* access intr_hwpmc_waiting_report_threshold cacheline
  only if at least one hook is loaded;