84879e46 asomers June 17, 2019, 11:34 p.m.
* Don't always write the last page synchronously.  That's not actually
  required.  It was probably just masking another bug that I fixed later,
  possibly in r349021.

* Enable the NotifyWriteback tests now that Writeback cache is working.

* Add a test to ensure that the write cache isn't flushed synchronously when
  in writeback mode.

Sponsored by:	The FreeBSD Foundation
cgit ViewVC
e68fcc88 takawata June 17, 2019, 11:03 p.m.
This adds ACPI device path on devinfo(8) output and
show  value of _UPC(usb port capabilities), _PLD (physical location of device)
when hw.usb.debug >= 1 .

Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D20630
cgit ViewVC
c1f64992 gjb June 17, 2019, 10:53 p.m.
SRC_CONF, __MAKE_CONF and SRCCONF, respectively) through
to arm_install_base() and chroot_arm_build_release().
This prevents failures when the target image is intended
to be build with make.conf(5) and src.conf(5) overrides,
which are correctly handled for non-embedded image builds.

Reported and tested by:	Daniel Engberg
PR:		238615
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation
cgit ViewVC
0482ec3e asomers June 17, 2019, 10:13 p.m.
Sponsored by:	The FreeBSD Foundation
cgit ViewVC
402b609c asomers June 17, 2019, 10:01 p.m.
fusefs will now use cluster_read.  This allows readahead of more than one
cache block.  However, it won't yet actually cluster the reads because that
requires VOP_BMAP, which fusefs does not yet implement.

Sponsored by:	The FreeBSD Foundation
cgit ViewVC
b6bb4d1e sevan June 17, 2019, 9:46 p.m.
d5646db9 sevan June 17, 2019, 9:38 p.m.
179f6280 cem June 17, 2019, 8:29 p.m.
Add experimental feature to increase concurrency in Fortuna.  As this
diverges slightly from canonical Fortuna, and due to the security
sensitivity of random(4), it is off by default.  To enable it, set the
tunable kern.random.fortuna.concurrent_read="1".  The rest of this commit
message describes the behavior when enabled.

Readers continue to update shared Fortuna state under global mutex, as they
do in the status quo implementation of the algorithm, but shift the actual
PRF generation out from under the global lock.  This massively reduces the
CPU time readers spend holding the global lock, allowing for increased
concurrency on SMP systems and less bullying of the harvestq kthread.

It is somewhat of a deviation from FS&K.  I think the primary difference is
that the specific sequence of AES keys will differ if READ_RANDOM_UIO is
accessed concurrently (as the 2nd thread to take the mutex will no longer
receive a key derived from rekeying the first thread).  However, I believe
the goals of rekeying AES are maintained: trivially, we continue to rekey
every 1MB for the statistical property; and each consumer gets a
forward-secret, independent AES key for their PRF.

Since Chacha doesn't need to rekey for sequences of any length, this change
makes no difference to the sequence of Chacha keys and PRF generated when
Chacha is used in place of AES.

On a GENERIC 4-thread VM (so, INVARIANTS/WITNESS, numbers not necessarily
representative), 3x concurrent AES performance jumped from ~55 MiB/s per
thread to ~197 MB/s per thread.  Concurrent Chacha20 at 3 threads went from
roughly ~113 MB/s per thread to ~430 MB/s per thread.

Prior to this change, the system was extremely unresponsive with 3-4
concurrent random readers; each thread had high variance in latency and
throughput, depending on who got lucky and won the lock.  "rand_harvestq"
thread CPU use was high (double digits), seemingly due to spinning on the
global lock.

After the change, concurrent random readers and the system in general are
much more responsive, and rand_harvestq CPU use dropped to basically zero.

Tests are added to the devrandom suite to ensure the uint128_add64 primitive
utilized by unlocked read functions to specification.

Reviewed by:	markm
Approved by:	secteam(delphij)
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D20313
cgit ViewVC
2b951e9c cy June 17, 2019, 8:11 p.m.
hostapd from ports instead of the one in base. The default is the hostapd
in base.

PR:		238571
MFC after:	1 week
cgit ViewVC
b8358917 cy June 17, 2019, 8:10 p.m.
structures that are saved across reboots by ipfs(8). The table is not
changed at runtime.

MFC after:	3 days
cgit ViewVC
f89d2072 delphij June 17, 2019, 7:49 p.m.
rename the source to gsb_crc32.c.

This is a prerequisite of unifying kernel zlib instances.

PR:		229763
Submitted by:	Yoshihiro Ota <ota at j.email.ne.jp>
Differential Revision:	https://reviews.freebsd.org/D20193
cgit ViewVC
2d4a74d7 zeising June 17, 2019, 5:35 p.m.
It is customary to use plural when talking about PCI configure registers.

Reported by:	scottl
MFC after:	2 weeks
X-MFC-with:	r349133
cgit ViewVC
6fa772a8 asomers June 17, 2019, 5:17 p.m.
fusefs doesn't not allow mmap when data caching is disabled.

Sponsored by:	The FreeBSD Foundation
cgit ViewVC
970a1ed3 markj June 17, 2019, 4:57 p.m.
MFC after:	3 days
cgit ViewVC
d569012f asomers June 17, 2019, 4:56 p.m.
fusefs will now read ahead at most one cache block at a time (usually 64
KB).  Clustered reads are still TODO.  Individual file systems may disable
read ahead by setting fuse_init_out.max_readahead=0 during initialization.

Sponsored by:	The FreeBSD Foundation
cgit ViewVC