12f3888a trasz May 2, 2019, 8:17 a.m.
That makes Linux lscpu(1) work.

Reviewed by:	dchagin
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D20131
cgit ViewVC
b4698b7a jhibbits May 2, 2019, 3:39 a.m.
It's possible for a Hypervisor Maintenance Interrupt (HMI) to occur while in
the pmap code, holding locks.  This can cause WITNESS to panic due to lock
errors in calling pmap_kextract().  Since we don't yet handle the flags
returned by OPAL_HANDLE_HMI2, just stop using it, so that we don't call into
pmap_kextract().

Reported by:	pkubaj
cgit ViewVC
85bdc684 behlendorf1 May 2, 2019, 12:34 a.m.
Currently, it is possible for the 'zpool scrub' command to
progress slightly beyond 100% due to concurrent changes
happening on the live pool. This behavior is expected, but
the userspace code for 'zpool status' would subtract the
expected amount of data from the amount of data already
scrubbed, resulting in a negative integer being casted to a
large positive one. This number was then used to calculate
the estimated completion time, resulting in wildly wrong
results. This code changes the behavior so that 'zpool status'
does not attempt to report an estimate during this period.

Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #8611 
Closes #8687
cgit
6bdefad3 behlendorf1 May 2, 2019, 12:32 a.m.
This comment seems to misunderstand the ## preprocessor token, which
does token concatenation.  It is not needed here, since we are
concatenating string literals, which is performed by putting the
literals next to each other.

Additionally, the comment uses offensive language.

Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #8698
Closes #8699
cgit
98ce554a trasz May 1, 2019, 7:35 p.m.
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
cgit ViewVC
f35f34b1 trasz May 1, 2019, 6:56 p.m.
also includes that.

Reviewed by:	cem
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D20130
cgit ViewVC
7a42decc trasz May 1, 2019, 6:54 p.m.
Reviewed by:	ngie
MFC after:	2 weeks
Sponsored by:	Klara Inc.
Differential Revision:	https://reviews.freebsd.org/D20125
cgit ViewVC
72f03b7c asomers May 1, 2019, 5:27 p.m.
These panics all lie in the error path.  The only one I've hit is caused by
a buggy FUSE server unexpectedly changing the type of a vnode.

Sponsored by:	The FreeBSD Foundation
cgit ViewVC
93198e64 asomers May 1, 2019, 5:24 p.m.
PR:		216391
Sponsored by:	The FreeBSD Foundation
cgit ViewVC
fa19730c andrew May 1, 2019, 5:12 p.m.
Some UEFI implementations trash this register and, as we use it as a
platform register, the kernel doesn't save it before calling into the UEFI
runtime services. As we have a copy in tpidr_el1 restore from there when
exiting the EFI environment.

PR:		237234, 237055
Reviewed by:	manu
Tested On:	Ampere eMAG
MFC after:	2 weeks
Sponsored by:	DARPA, AFRL
Sponsored by:	Ampere Computing (hardware)
Differential Revision:	https://reviews.freebsd.org/D20127
cgit ViewVC
8beadca5 markj May 1, 2019, 3:28 p.m.
These are intended to exercise some rarely executed code paths.

MFC after:	2 weeks
cgit ViewVC
adf208e7 br May 1, 2019, 3:03 p.m.
This is the part of INTRNG support that was missed.

Sponsored by:	DARPA, AFRL
cgit ViewVC
65f1fc3f ganbold May 1, 2019, 2:20 p.m.
Reviewed by:	andrew, manu
Differential Revision:	https://reviews.freebsd.org/D20123
cgit ViewVC
19f5d9f2 kib May 1, 2019, 1:15 p.m.
vm_map_wire() increments entry->wire_count, after that it drops the
map lock both for faulting in the entry' pages, and for marking next
entry in the requested region as IN_TRANSITION. Only after all entries
are faulted in, MAP_ENTRY_USER_WIRE flag is set.

This makes it possible for vm_map_protect() to run while other entry'
MAP_ENTRY_IN_TRANSITION flag is handled, and vm_map_busy() lock does
not prevent it. In particular, if the call to vm_map_protect() adds
VM_PROT_WRITE to CoW entry, it would fail to call
vm_fault_copy_entry(). There are at least two consequences of the
race: the top object in the shadow chain is not populated with
writeable pages, and second, the entry eventually get contradictory
flags MAP_ENTRY_NEEDS_COPY | MAP_ENTRY_USER_WIRED with VM_PROT_WRITE
set.

Handle it by waiting for all MAP_ENTRY_IN_TRANSITION flags to go away
in vm_map_protect(), which does not drop map lock afterwards. Note
that vm_map_busy_wait() is left as is.

Reported and tested by:	pho (previous version)
Reviewed by:	Doug Moore <dougm@rice.edu>, markj
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D20091
cgit ViewVC
7e89a7e3 trasz May 1, 2019, 1 p.m.
them just fine.

MFC after:	2 weeks
Sponsored by:	DARPA, AFRL
cgit ViewVC