8c280db0 allanjude Feb. 18, 2021, 3:48 p.m.
As per Intelligent Platform Management Interface Specification v2.0 rev. 1.1,
section 12.5: SSIF Multi-part Read Transactions

Sponsored by:	Ampere Computing LLC
Submitted by:	Klara Inc.
Reviewed by:	manu
Differential Revision:	https://reviews.freebsd.org/D28749
37ef8d4c allanjude Feb. 18, 2021, 3:47 p.m.
Per the i2c spec, a slave device can stretch SCL idefinitely, so 25ms is
a bit arbitrary in general. smbus does specify an optional timeout
recovery mechanism to be done at about 25~35ms, but the IPMI SSIF spec
says that BMCs don't have any obligation to implement that.
The BMC on Altra seems to mostly respond within 25ms, but occasionally
will stretch SCL for ~300 msec.

Also, the count_us mechanism seems to actually timeout around 25%
earlier than it would claim (timeout really happening around 19ms
instead of 25ms).

Sponsored by:	Ampere Computing LLC
Submitted by:	Klara Inc.
Reviewed by:	manu, imp
Differential Revision:	https://reviews.freebsd.org/D28747
0577e39b fernape Feb. 18, 2021, 2:59 p.m.
Some ibnd_* manpages source other manpages from a `man3/` directory when it
should reference the pages in the current directory.

Instead of modifying contributing sources and using `.so` (discouraged by
mandoc(1)) use MLINKS in the proper Makefile and do not install the affected

PR: 237693
Reported by: wosch@FreeBSD.org
Reviewed by: gbe@ (mentor) yuripv@
Approved by: gbe@ (mentor) yuripv@
Differential Revision: https://reviews.freebsd.org/D28727
662283b1 kib Feb. 18, 2021, 2:28 p.m.
Noted by:	mjg
Sponsored by:	The FreeBSD Foundation
MFC after:	6 days
Fixes:	fa3bd463cee
10f57cb9 mm Feb. 18, 2021, 2:21 p.m.
- bump version to 2.0.0-FreeBSD_gbf156c966
- install definition files for the new "-o compatibility" option
  to "zpool create"

MFC after:	2 weeks
ee36e25a mm Feb. 18, 2021, 2:19 p.m.
Notable upstream changes:
    bf156c966 Remove unused abd_alloc_scatter_offset_chunkcnt
    658fb8020 Add "compatibility" property for zpool feature sets

This update introduces a new pool property called "compatibility"
that can be used to enable a limited set of pool features on pool
creation and "stick" to it, so the "zpool upgrade" does not
accidentally enable features that are not desired. The value of
this property may then be changed later.

See zpool-features(5) for more information about the "compatibility"
pool property.

Obtained from:	OpenZFS
MFC after:	2 weeks
fa2528ac arichardson Feb. 18, 2021, 2:02 p.m.
KCSAN complains about racy accesses in the locking code. Those races are
fine since they are inside a TD_SET_RUNNING() loop that expects the value
to be changed by another CPU.

Use relaxed atomic stores/loads to indicate that this variable can be
written/read by multiple CPUs at the same time. This will also prevent
the compiler from doing unexpected re-ordering.

Reported by:	GENERIC-KCSAN
Test Plan:	KCSAN no longer complains, kernel still runs fine.
Reviewed By:	markj, mjg (earlier version)
Differential Revision: https://reviews.freebsd.org/D28569
df093aa9 arichardson Feb. 18, 2021, 2:02 p.m.
In the CheriBSD CI we reproducibly see the first test in sys/audit
(administrative:acct_failure) fail due to a missing startup message.
It appears this is caused by a race condition when starting auditd:
`service auditd onestart` returns as soon as the initial auditd() parent
exits (after the daemon(3) call).
We can avoid this problem by setting up the auditd infrastructure
in-process: libauditd contains audit_quick_{start,stop}() functions that
look like they are ideally suited to this task.
This patch also avoids forking lots of shell processes for each of the 418
tests by using `auditon(A_SENDTRIGGER, &trigger, sizeof(trigger))` to check
for a running auditd(8) instead of using `service auditd onestatus`.

With these two changes (and D28388 to fix the XFAIL'd test) I can now
boot and run `cd /usr/tests/sys/audit && kyua test` without any failures
in a single-core QEMU instance. Before there would always be at least one
failed test.

Besides making the tests more reliable in CI, a nice side-effect of this
change is that it also significantly speeds up running them by avoiding
lots of fork()/execve() caused by shell scripts:
Running kyua test on an AArch64 QEMU took 315s before and now takes 68s,
so it's roughly 3.5 times faster. This effect is even larger when running
on a CHERI-RISC-V QEMU since emulating CHERI instructions on an x86 host
is noticeably slower than emulating AArch64.

Test Plan: aarch64+amd64 QEMU no longer fail.

Reviewed By:	asomers
Differential Revision: https://reviews.freebsd.org/D28451
cbcfe28f arichardson Feb. 18, 2021, 2:02 p.m.
This causes problems when using ASAN with a runtime older than 12.0 since
the intercept does not expect qsort() to call itself using an interposable
function call. This results in infinite recursion and stack exhaustion
when a binary compiled with -fsanitize=address calls qsort.
See also https://bugs.llvm.org/show_bug.cgi?id=46832 and
https://reviews.llvm.org/D84509 (ASAN runtime patch).

To prevent this problem, this patch uses a static helper function
for the actual qsort() implementation. This prevents interposition and
allows for direct calls. As a nice side-effect, we can also move the
qsort_s checks to the top-level function and out of the recursive calls.

Reviewed By:	kib
Differential Revision: https://reviews.freebsd.org/D28133
2aa3ef28 arichardson Feb. 18, 2021, 2:02 p.m.
Since https://github.com/freebsd/atf/commit/4581cefc1e3811dd3c926b5dd4b15fd63d2e19da
ATF opens the results file on startup. This fixes problems like
capsicumized tests not being able to open the file on exit.

However, this test closes all file descriptors above 3 to get a
deterministic fd table allocation for the child. Instead of using closefrom
(which will close the ATF output file FD) I've changed this test use
the lowest available fd and pass that to the helper program as a string.

We could also try to re-open the results file in ATF if we get a EBADF
error, but that will fail when running under Capsicum.

Reviewed By:	cem
Differential Revision: https://reviews.freebsd.org/D28684
1c808fcd mw Feb. 18, 2021, 12:54 p.m.
In the new ENA-based instances like c6gn, the vector table moved to a
new PCIe bar - BAR1. Previously it was always located on the BAR0, so
the resources were already allocated together with the registers.

As the FreeBSD isn't doing any resource allocation behind the scenes,
the driver is responsible to allocate them explicitly, before other
parts of the OS (like the PCI code allocating MSIx) will be able to
access them.

To determine dynamically BAR on which the MSIx vector table is present
the pci_msix_table_bar() is being used and the new BAR is allocated if

Submitted by: Michal Krawczyk <mk@semihalf.com>
Obtained from: Semihalf
Sponsored by: Amazon, Inc
MFC after: 3 days
e13e4fa6 rrs Feb. 18, 2021, 12:29 p.m.
fae028dd np Feb. 18, 2021, 9:22 a.m.
Read the PF-only hardware settings directly in get_params__post_init.
Split the rest into two routines used by both the PF and VF drivers: one
that reads the SGE rx buffer configuration and another that verifies
miscellaneous hardware configuration.

MFC after:	1 week
Sponsored by:	Chelsio Communications
2ed689a6 kp Feb. 18, 2021, 7:38 a.m.
pf_rule_to_krule() incorrectly converted the rule osfp configuration to
the krule structure.

Reported by:	delphij@
MFC after:	3 days
0a4f8510 rrs Feb. 18, 2021, 6:27 a.m.