d765b211 andrew Feb. 19, 2021, 3:31 p.m.
XScale support was removed over 2 years ago, remove the last __XSCALE__
checks from the arm MD code.

Sponsored by:	Innovate UK
853fd7a2 rscheff Feb. 19, 2021, 12:55 p.m.
Under some circumstances, PRR may end up with a fully
collapsed cwnd when finalizing the loss recovery.

Reviewed By:	#transport, kbowling
Reported by:	Liang Tian
MFC after:	1 week
Sponsored by:	NetApp, Inc.
Differential Revision:	https://reviews.freebsd.org/D28780
248a47a4 debdrup Feb. 19, 2021, 12:42 p.m.
Packages default to ending up in a different location compared to the
documentation, so catch up to the implementation by referring to the
location where packages can usually be found if no environment variables
have been set.

While here, also update the mention of the file extension to match the
txz format that packages use.

PR:		253179, 224370
Reported by:	rwatson, jeromer at fastmail dotnet
4c0bef07 kevans Feb. 19, 2021, 4:36 a.m.
TCP_LINGERTIME can be traced back to BSD 4.4 Lite and perhaps beyond, in
exactly the same form that it appears here modulo slightly different
context.  It used to be the case that there was a single pr_usrreq
method with requests dispatched to it; these exact two lines appeared in
tcp_usrreq's PRU_ATTACH handling.

The only purpose of this that I can find is to cause surprising behavior
on accepted connections. Newly-created sockets will never hit these
paths as one cannot set SO_LINGER prior to socket(2). If SO_LINGER is
set on a listening socket and inherited, one would expect the timeout to
be inherited rather than changed arbitrarily like this -- noting that
SO_LINGER is nonsense on a listening socket beyond inheritance, since
they cannot be 'connected' by definition.

Neither Illumos nor Linux reset the timer like this based on testing and
inspection of Illumos, and testing of Linux.

Reviewed by:	rscheff, tuexen
Differential Revision:	https://reviews.freebsd.org/D28265
812c9f48 mav Feb. 19, 2021, 3:29 a.m.
Introduce new CTL core KPI ctl_run(), preprocessing I/Os in the caller
context instead of scheduling another thread just for that.  This call
may sleep, that is not acceptable for some frontends like the original
CAM/FC one, but iSCSI already has separate sleepable per-connection RX
threads, and another thread scheduling is mostly just a waste of time.
IOCTL frontend actually waits for the I/O completion in the caller
thread, so the use of another thread for this has even less sense.

With this change I can measure ~5% IOPS improvement on 4KB iSCSI I/Os
to ZFS.

MFC after:	1 month
4621c4f2 emaste Feb. 19, 2021, 1:45 a.m.
df093aa9463b linked against libprivateauditd.a, but that is currently
(and incorrectly) built as position-dependent.  For now just force PIE
off for this test to fix the WITH_PIE build.

Sponsored by:	The FreeBSD Foundation
80ab50e1 gjb Feb. 18, 2021, 11:53 p.m.
MFC after:	1 week
Sponsored by:	Rubicon Communications, LLC ("Netgate")
e7adccf7 noreply Feb. 18, 2021, 11:51 p.m.
First, the crypto request completion handler contains a bug in that it
fails to reset fs_done correctly after the request is completed.  This
is only a problem for asynchronous drivers.  Second, some hardware
drivers have input constraints which ZFS does not satisfy.  For
instance, ccp(4) apparently requires the AAD length for AES-GCM to be a
multiple of the cipher block size, and with qat(4) the AES-GCM AAD
length may not be longer than 240 bytes.  FreeBSD's generic crypto
framework doesn't have a mechanism to automatically fall back to a
software implementation if a hardware driver cannot process a request,
and ZFS does not tolerate such errors.

The plan is to implement such a fallback mechanism, but with FreeBSD
13.0 approaching we should simply disable the use hardware drivers for

Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Signed-off-by: Mark Johnston <markj@FreeBSD.org>
Closes #11612
bdde49b7 rpokala Feb. 18, 2021, 11:08 p.m.
The ACPI NFIT specification defines a set of "NVDIMM State Flags". These
flags are already reported by `acpidump -t', but this change makes them
available on a per-device basis, in a format that is more easily parsed.

To simplify this, introduce acpi_nfit_get_memory_maps_by_dimm(), which
locates the (ACPI_NFIT_MEMORY_MAP)s associated with a given

Reviewed by:	mav, cem
Tested by:	mav, rpokala (version for stable/12)
MFC after:	3 days
Sponsored by:	Panasas
2f48313a rmacklem Feb. 18, 2021, 10:38 p.m.
Add rc.d scripts that control the recently committed rpc.tlsclntd(8)
and rpc.tlsservd(8) daemons.

Reviewed by:	gbe
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D28432
b9cbc85d rmacklem Feb. 18, 2021, 10:15 p.m.
The kernel changes needed for nfs-over-tls have been committed to main.
However, nfs-over-tls requires user space daemons to handle the
TLS handshake and other non-application data TLS records.
There is one daemon (rpc.tlsclntd) for the client side and one daemon
(rpc.tlsservd) for the server side, although they share a fair amount
of code found in rpc.tlscommon.c and rpc.tlscommon.h.
They use a KTLS enabled OpenSSL to perform the actual work and, as such,
are only built when MK_OPENSSL_KTLS is set.
Communication with the kernel is done via upcall RPCs done on AF_LOCAL
sockets and the custom system call rpctls_syscall.

Reviewed by:	gbe (man pages only), jhb (usr.sbin/Makefile only)
Comments by:	jhb
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D28430
Relnotes:	yes
778869fa noreply Feb. 18, 2021, 9:53 p.m.
That happens because of an off-by-one mistake.
share_mount_one_cb() calls report_mount_progress(current=sm_done) after
having incremented sm_done by one.  Then report_mount_progress()
increments the parameter again.  It appears that that logic became
obsolete after commit a10d50f999511, parallel zfs mount.

On FreeBSD I observe that zfs mount -a -v prints, for example,
    (null): (201/248)
That happens because set_progress_header() is never called.

With this change the output becomes correct:
    Mounting ZFS filesystems: (209/248)

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Andriy Gapon <avg@FreeBSD.org>
Closes #11607
c67a2909 mav Feb. 18, 2021, 9:31 p.m.
It is a rare, but still better to not have lock dependencies.

MFC after:	1 month
0ee0dbfb dim Feb. 18, 2021, 9:30 p.m.
Interesting fixes:
b3c73ba libelftc_dem_gnu3: Sync with elftoolchain r3877
7b2335c Mostly fix __cxa_demangle after #3

Reported by:	arichardson
PR:		253226
MFC after:	3 days
04d2d2d7 mhorne Feb. 18, 2021, 9:17 p.m.
BUS_DMA_NOCACHE should only be used when one needs to guarantee the
created mapping has uncached memory attributes, usually as a result
of buggy hardware. Normal use cases should pass BUS_DMA_COHERENT, to
create an appropriate mapping based on the flags passed to

This should have no functional change, since the DMA tags in this driver
are created without the BUS_DMA_COHERENT flag.

Reported by:	mmel
Reviewed by:	mmel, Thomas Skibo <thomas-bsd@skibo.net>
MFC after:	3 days