r353725 yuripv Oct. 18, 2019, 12:25 p.m.
Move futex_mtx to linux_common.ko for amd64 and aarch64 along
with respective list/mutex init/destroy.

PR:		240989
Reported by:	Alex S <iwtcex@gmail.com>
r353724 yuripv Oct. 18, 2019, 10:28 a.m.
Move futex_list definition to linux.c which is included once
in linux.ko (i386) and in linux_common.ko (amd64 and aarch64)
allowing 32/64 bit linux programs to access the same futexes
in the latter case.

PR:		240989
Reviewed by:	dchagin
Differential Revision:	https://reviews.freebsd.org/D22073
r353718 phk Oct. 18, 2019, 7:55 a.m.
when variance is small relative to data points.

Now [0, 1, 2] shows same standard deviation as [10000000000000, ...1, ...2]

Also:  Various nitpickery from my own tree.
r353715 kp Oct. 18, 2019, 3:36 a.m.
icmp_reflect(), called through icmp_error() requires us to be in NET_EPOCH.
Failure to hold it leads to the following panic (with INVARIANTS):

  panic: Assertion in_epoch(net_epoch_preempt) failed at /usr/src/sys/netinet/ip_icmp.c:742
  cpuid = 2
  time = 1571233273
  KDB: stack backtrace:
  db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e0977920
  vpanic() at vpanic+0x17e/frame 0xfffffe00e0977980
  panic() at panic+0x43/frame 0xfffffe00e09779e0
  icmp_reflect() at icmp_reflect+0x625/frame 0xfffffe00e0977aa0
  icmp_error() at icmp_error+0x720/frame 0xfffffe00e0977b10
  pf_intr() at pf_intr+0xd5/frame 0xfffffe00e0977b50
  ithread_loop() at ithread_loop+0x1c6/frame 0xfffffe00e0977bb0
  fork_exit() at fork_exit+0x80/frame 0xfffffe00e0977bf0
  fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e0977bf0

Note that we now enter NET_EPOCH twice if we enter ip_output() from pf_intr(),
but ip_output() will soon be converted to a function that requires epoch, so
entering NET_EPOCH directly from pf_intr() makes more sense.

Discussed with:	glebius@
r353714 cem Oct. 18, 2019, 3:01 a.m.
The sentinel value for "use the rest of the region," -1, isn't zero modulo
PAGE_SIZE.  Relax the check to permit the intended special value.

X-MFC-With:	r353110
Sponsored by:	Dell EMC Isilon
r353713 cem Oct. 18, 2019, 2:25 a.m.
It was in my git tree (uncommitted) and didn't get carried over to SVN in

X-MFC-With:	r353712
r353712 cem Oct. 18, 2019, 2:18 a.m.
Rather than a few scattered places in the tree.  Organize flag names in a
contiguous region of specialreg.h.

While here, delete deprecated PCOMMIT from leaf 7.

No functional change.
r353711 mhorne Oct. 18, 2019, 1:46 a.m.
Reviewed by:	dim
MFC with:	r353358
Differential Revision:	https://reviews.freebsd.org/D21963
r353709 brooks Oct. 18, 2019, midnight
CLANG_NO_IAS was removed in r351661.
r353702 cem Oct. 17, 2019, 10:37 p.m.
When the underlying debugport transport is reliable, GDB's additional
checksums and acknowledgements are redundant.  NoAckMode eliminates the
the acks and allows us to skip checking RX checksums.  The GDB packet
framing does not change, so unfortunately (valid) checksums are still
included as message trailers.

The gdb(4) stub in FreeBSD advertises support for the feature in response to
the client's 'qSupported' request IFF the current debugport has the
gdb_dbfeatures flag GDB_DBGP_FEAT_RELIABLE set.  Currently, only netgdb(4)
supports this feature.

If the remote GDB client supports the feature and does not have it disabled
via a GDB configuration knob, it may instruct our gdb(4) stub to enter
NoAckMode.  Unless and until it issues that command, we must continue to
transmit acks as usual (and for now, we continue to wait until we receive
them as well, even if we know the debugport is on a reliable transport).

In the kernel sources, the sense of the flag representing the state of the
feature is reversed from that of the GDB command.  (I.e., it is
'gdb_ackmode', not 'gdb_noackmode.')  This is to avoid confusing double-
negative conditions.

For reference, see:
  * https://sourceware.org/gdb/onlinedocs/gdb/Packet-Acknowledgment.html
  * https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#QStartNoAckMode

Reviewed by:	jhb, markj (both earlier version)
Differential Revision:	https://reviews.freebsd.org/D21761
r353701 markj Oct. 17, 2019, 9:39 p.m.
Use it to pad the text and read-only data sections to a 4KB boundary.
This will be used to enforce strict memory protections for some
sections of loadable kernel modules.

Reviewed by:	kib
MFC after:	2 weeks
Sponsored by:	Netflix
Differential Revision:	https://reviews.freebsd.org/D21970
r353700 cem Oct. 17, 2019, 9:33 p.m.
NetGDB(4) is a component of a system using a panic-time network stack to
remotely debug crashed FreeBSD kernels over the network, instead of
traditional serial interfaces.

There are three pieces in the complete NetGDB system.

First, a dedicated proxy server must be running to accept connections from
both NetGDB and gdb(1), and pass bidirectional traffic between the two

Second, the NetGDB client is activated much like ordinary 'gdb' and
similarly to 'netdump' in ddb(4) after a panic.  Like other debugnet(4)
clients (netdump(4)), the network interface on the route to the proxy server
must be online and support debugnet(4).

Finally, the remote (k)gdb(1) uses 'target remote <proxy>:<port>' (like any
other TCP remote) to connect to the proxy server.

The NetGDB v1 protocol speaks the literal GDB remote serial protocol, and
uses a 1:1 relationship between GDB packets and sequences of debugnet
packets (fragmented by MTU).  There is no encryption utilized to keep
debugging sessions private, so this is only appropriate for local
segments or trusted networks.

Submitted by:	John Reimer <john.reimer AT emc.com> (earlier version)
Discussed some with:	emaste, markj
Relnotes:	sure
Differential Revision:	https://reviews.freebsd.org/D21568
r353699 markj Oct. 17, 2019, 9:25 p.m.
- Remove a redundant assignment of ef->address.
- Don't return a Mach error number to the caller if vm_map_find() fails.
- Use ptoa() and fix style.

MFC after:	2 weeks
Sponsored by:	Netflix
r353698 markj Oct. 17, 2019, 8:46 p.m.
At least one small update to the out-of-tree DRM drivers is required
now that cdev_pager_free_page() expects an xbusy page.

Discussed with:	jeff, zeising
r353697 sjg Oct. 17, 2019, 8:40 p.m.
PATH_BOOTABLE_TOKEN can be set to a non-standard
path that identifies a device as bootable.

Reviewed by: kevans, bcran
Differential Revision:  https://reviews.freebsd.org/D22062