r354637 royger Nov. 12, 2019, 10:31 a.m.
Currently NMIs are sent over event channels, but that defeats the
purpose of NMIs since event channels can be masked. Fix this by
issuing NMIs using a hypercall, which injects a NMI (vector #2) to the
desired vCPU.

Note that NMIs could also be triggered using the emulated local APIC,
but using a hypercall is better from a performance point of view
since it doesn't involve instruction decoding when not using x2APIC

Reported and Tested by:	avg
Sponsored by:		Citrix Systems R&D
r354635 tsoome Nov. 12, 2019, 10:02 a.m.
In our case the structure is more complex and simple static initializer
will upset compiler diagnostics - using memset is still better than building
more complext initializer.
r354633 karels Nov. 12, 2019, 1:03 a.m.
The code for "netstat -gs -f inet" failed if the kernel namelist did not
include the _mrtstat symbol. However, that symbol is not in a standard
kernel even with the ip_mroute module loaded, where the functionality is
available. It is also not in a kernel with MROUTING but also VIMAGE, as
there can be multiple sets of stats. However, when running the command
on a live system, the symbol is not used; a sysctl is used. Go ahead
and try the sysctl in any case, and complain that IPv4 MROUTING is not
present only if the sysctl fails with ENOENT. Also fail if _mrtstat is
not defined when running on a core file; netstat doesn't know about vnets,
so can only work if MROUTING was included, and VIMAGE was not.

Reviewed by:	bz
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D22311
r354632 chs Nov. 12, 2019, 12:32 a.m.
Reviewed by:	kib, mckusick
Approved by:	imp (mentor)
Sponsored by:	Netflix
r354631 scottl Nov. 11, 2019, 10:18 p.m.
r354630 kib Nov. 11, 2019, 9:59 p.m.
On some AMD CPUs, in particular, machines that do not implement
CLFLUSHOPT but do provide CLFLUSH, the CLFLUSH instruction is only
synchronized with MFENCE.

Code using CLFLUSH typicall needs to brace it with MFENCE both before
and after flush, see for instance pmap_invalidate_cache_range().  If
context switch occurs while inside the protected region, we need to
ensure visibility of flushes done on the old CPU, to new CPU.

For all other machines, locked operation done to lock switched thread,
should be enough.  For case of different address spaces, reload of
%cr3 is serializing.

Reviewed by:	cem, jhb, scottph
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D22007
r354629 markj Nov. 11, 2019, 8:44 p.m.
Suppose a writing thread has pinned its pages and gone to sleep with
pipe_map.cnt > 0.  Suppose that the thread is woken up by a signal (so
error != 0) and the other end of the pipe has simultaneously been
closed.  In this case, to satisfy the assertion about pipe_map.cnt in
pipe_destroy_write_buffer(), we must mark the buffer as empty.

Reported by:	syzbot+5cce271bf2cb1b1e1876@syzkaller.appspotmail.com
Reviewed by:	kib
Tested by:	pho
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D22261
r354627 avg Nov. 11, 2019, 7:06 p.m.
This change removes TRAP_INTERRUPT and TRAP_TIMERINT frame types.

Their names are a bit confusing: trap + interrupt, what is that?
The TRAP_TIMERINT name is too specific -- can it only be used for timer
"trap-interrupts"?  What is so special about them?

My understanding of the code is that INTERRUPT, TRAP_INTERRUPT and
TRAP_TIMERINT differ only in how an offset from callee's frame pointer to a
trap frame on the stack is calculated.  And that depends on a number of
arguments that a special handler passes to a callee (a function with a
normal C calling convention).

So, this change makes that logic explicit and collapses all interrupt frame
types into the INTERRUPT type.

Reviewed by:	markj
Discussed with:	kib, jhb
MFC after:	3 weeks
Differential Revision: https://reviews.freebsd.org/D22303
r354625 dim Nov. 11, 2019, 5:41 p.m.
[libc++] Harden usage of static_assert against C++03

  In C++03, we emulate static_assert with a macro, and we must
  parenthesize multiple arguments.

  llvm-svn: 373328

This is a follow-up to r354460, which causes errors for pre-C++11
programs using <cmath>, similar to:

/usr/include/c++/v1/cmath:622:68: error: too many arguments provided to
function-like macro invocation

Reported by:	antoine
MFC after:	immediately (because of ports breakage)
r354624 vangyzen Nov. 11, 2019, 5:41 p.m.
If cu reads an EOF on the input side, it goes into a tight loop
sending a garbage byte to the remote.  With this change, it exits
gracefully, along with its child.

MFC after:	2 weeks
Sponsored by:	Dell EMC Isilon
r354623 imp Nov. 11, 2019, 5:36 p.m.
For the PROBEWP and PROBERC* states, add assertiosn that both the da device
state is in the right state, as well as the ccb state is the right one when we
enter dadone_probe{wp,rc}. This will ensure that we don't sneak through when
we're re-probing the size and write protection status of the device and thereby
leak a reference which can later lead to an invalidated peripheral going away
before all references are released (and resulting panic).

Reviewed by: scottl, ken
Differential Revision: https://reviews.freebsd.org/D22295
r354622 imp Nov. 11, 2019, 5:36 p.m.
There are contexts where releasing the ccb triggers dastart() to be run
inline. When da was written, there was always a deferral, so it didn't matter
much. Now, with direct dispatch, we can call dastart from the dadone*
routines. If the probe state isn't updated, then dastart will redo things with
stale information. This normally isn't a problem, because we run the probe state
machine once at boot... Except that we also run it for each open of the device,
which means we can have multiple threads racing each other to try to kick off
the probe. However, if we update the state before we release the CCB, we can
avoid the race. While it's needed only for the probewp and proberc* states, do
it everywhere because it won't hurt the other places.

The race here happens because we reprobe dozens of times on boot when drives
have lots of partitions.  We should consider caching this info for 1-2 seconds
to avoid this thundering hurd.

Reviewed by: scottl, ken
Differential Revision: https://reviews.freebsd.org/D22295
r354621 imp Nov. 11, 2019, 5:36 p.m.
Reviewed by: scottl, ken
Differential Revision: https://reviews.freebsd.org/D22295
r354620 imp Nov. 11, 2019, 5:36 p.m.
Reviewed by: scottl, ken
Differential Revision: https://reviews.freebsd.org/D22295
r354619 avg Nov. 11, 2019, 5:11 p.m.
Besides the confusing name, this type is effectively unused.
In all cases where it could be set, the INTERRUPT type is set by the
earlier code.  The conditions for TRAP_INTERRUPT are a subset of the
conditions for INTERRUPT.

Reviewed by:	kib, markj
MFC after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D22305