From Jake:

In r341156 ("Fix first-packet completion", 2018-11-28) a hack to work
around a delta calculation determining how many descriptors were used
was added to ixl_isc_tx_credits_update_dwb.

The same fix was also applied to the em and igb drivers in r340310, and
to ix in r341156.

The hack checked the case where prev and cur were equal, and then added
one. This works, because by the time we do the delta check, we already
know there is at least one packet available, so the delta should be at
least one.

However, it's not a complete fix, and as indicated by the comment is
really a hack to work around the real bug.

The real problem is that the first time that we transmit a packet,
tx_cidx_processed will be set to point to the start of the ring.
Ultimately, the credits_update function expects it to point to the
*last* descriptor that was processed. Since we haven't yet processed any
descriptors, pointing it to 0 results in this incorrect calculation.

Fix the initialization code to have it point to the end of the ring
instead. One way to think about this, is that we are setting the value
to be one prior to the first available descriptor.

Doing so, corrects the delta calculation in all cases. The original fix
only works if the first packet has exactly one descriptor. Otherwise, we
will report 1 less than the correct value.

As part of this fix, also update the MPASS assertions to match the real
expectations. First, ensure that prev is not equal to cur, since this
should never happen. Second, remove the assertion about prev==0 || delta
!= 0. It looks like that originated from when the em driver was
converted to iflib. It seems like it was supposed to ensure that delta
was non-zero. However, because we originally returned 0 delta for the
first calculation, the "prev == 0" was tacked on.

Instead, replace this with a check that delta is greater than zero,
after the correction necessary when the ring pointers wrap around.

This new solution should fix the same bug as r341156 did, but in a more
robust way.

Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
Reviewed by:	shurd@
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D18545

I should have only changed the format qualifier with the `size_t` value,
`length`, not the other [`off_t`] value, `dest_file_size`.

MFC after:	1 month
MFC with:	r343362, r343365, r343367
Approved by:	emaste (mentor; implicit)
Reported by:	gcc 8.x

I should have used `%zu` instead of `%ju` with `size_t` types.

MFC after:	1 month
MFC with:	r343362, r343365
Approved by:	emaste (mentor; implicit)
Reviewed by:	asomers
Pointyhat to:	ngie
Submitted by:	asomers
Differential Revision: https://reviews.freebsd.org/D18935

This was a tangential change submitted as part of D18930.

Submitted by:	jack@gandi.net

gcc 8.x is more pedantic than clang 7.x with format strings and the tests
passed `void*` variables while supplying `%s` (which is technically
incorrect).

Make the affected `void*` variables use `char*` storage instead to address
this issue, as the compiler will upcast the values to `char*`.

MFC after:	1 month
MFC with:	r343362
Approved by:	emaste (mentor; implicit)
Reviewed by:	asomers
Differential Revision: https://reviews.freebsd.org/D18934

Reviewed by:	bz
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation

After the afdata read lock was converted to epoch(9), readers could
observe a linked LLE and block on the LLE while a thread was
unlinking the LLE.  The writer would then release the lock and schedule
the LLE for deferred free, allowing readers to continue and potentially
schedule the LLE timer.  By the point the timer fires, the structure is
freed, typically resulting in a crash in the callout subsystem.

Fix the problem by modifying the lookup path to check for the LLE_LINKED
flag upon acquiring the LLE lock.  If it's not set, the lookup fails.

PR:		234296
Reviewed by:	bz
Tested by:	sbruno, Victor <chernov_victor@list.ru>,
		Mike Andrews <mandrews@bit0.com>
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D18906

These testcases exercise a number of functional requirements for sendfile(2).

The testcases use IPv4 and IPv6 domain sockets with TCP, and were confirmed
functional on UFS and ZFS. UDP address family sockets cannot be used per the
sendfile(2) contract, thus using UDP sockets is outside the scope of
testing the syscall in positive cases. As seen in
`:s_negative_udp_socket_test`, UDP is used to test the sendfile(2) contract
to ensure that EINVAL is returned by sendfile(2).

The testcases added explicitly avoid testing out `SF_SYNC` due to the
complexity of verifying that support. However, this is a good next logical
item to verify.

The `hdtr_positive*` testcases work to a certain degree (the header
testcases pass), but the trailer testcases do not work (it is an expected
failure). In particular, the value received by the mock server doesn't match
the expected value, and instead looks something like the following (using
python array notation):

`trailer[:]message[1:]`

instead of:

`message[:]trailer[:]`

This makes me think there's a buffer overrun issue or problem with the
offset somewhere in the sendfile(2) system call, but I need to do some
other testing first to verify that the code is indeed sane, and my
assumptions/code isn't buggy.

The `sbytes_negative` testcases that check `sbytes` being set to an
invalid value resulting in `EFAULT` fails today as the other change
(which checks `copyout(9)`) has not been committed [1]. Thus, it
should remain an expected failure (see bug 232210 for more details
on this item).

Next steps for testing sendfile(2):
1. Fix the header/trailer testcases so that they pass.
2. Setup if_tap interface and test with it, instead of using "localhost", per
   @asomers's suggestion.
3. Handle short recv(2)'s in `server_cat(..)`.
4. Add `SF_SYNC` support.
5. Add some more negative tests outside the scope of the functional contract.

MFC after:	1 month
Reviewed by:	asomers
Approved by:	emaste (mentor)
PR: 		232210
Sponsored by:   Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D18625

We already call setutxent() once during initialization.  Furthermore,
the subsequent calls occur after the process has entered capability
mode, so they fail, and attempts to fetch database entries fail as
a result.

PR:		235096
Submitted by:	fullermd@over-yonder.net
MFC after:	3 days

The iterator should be reinitialized after every successful slab
allocation.  A request to advance the iterator is interpreted as
an allocation failure, so a sufficiently large preallocation would
cause the iterator to believe that all domains were exhausted,
resulting in a sleep with the keg lock held. [1]

Also, keg_alloc_slab() should pass the unmodified wait flag to the
item initialization routine, which may use it to perform allocations
from other zones.

Reported and tested by:	slavah
Diagnosed by:	kib [1]
Reviewed by:	kib
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation

Submitted by:		Gary Jennejohn <gljennjohn@gmail.com>
MFC after:		1 week
Sponsored by:		Mellanox Technologies

Approved by: mav
MFC after: 3 weeks

Note that the affected interface is available only to root.

admbugs:	765
Reported by:	Vlad Tsyrklevich <vlad@tsyrklevich.net>
Reviewed by:	emaste, ram
MFC after:	1 day
Security:	Kernel memory disclosure
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D18914

gmirror's sc_flags is shared between some on-disk state and some runtime
only state.  There's no real reason for that and they could probably be
split up.  Until they are, locate all of the flags for the same field
nearby each other in the source, for clarity.

No functional change.

Sponsored by:	Dell EMC Isilon

Changelist:
    - Add the proper memory barriers in the kloop ring processing
      functions.
    - Fix memory barriers usage in the user helpers (nm_sync_kloop_appl_write,
      nm_sync_kloop_appl_read).
    - Fix nm_kr_txempty() helper to look at rhead rather than rcur. This
      is important since the kloop can read a value of rcur which is ahead
      of the value of rhead (see explanation in nm_sync_kloop_appl_write)
    - Remove obsolete ptnetmap_guest_write_kring_csb() and
      ptnet_guest_read_kring_csb(), and update if_ptnet(4) to use those.
    - Prepare in advance the arguments for netmap_sync_kloop_[tr]x_ring(),
      to make the kloop faster.
    - Provide kernel and user implementation for nm_ldld_barrier() and
      nm_ldst_barrier()

MFC after:	2 weeks

The nm_os_selwakeup function needs to call knote() to wake up kqueue(9)
users. However, this function can be called from different code paths,
with different lock requirements.
This patch fixes the knote() call argument to match the relavant lock state.
Also, comments have been updated to reflect current code.

PR:	https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219846
Reported by:	Aleksandr Fedorov <aleksandr.fedorov@itglobal.com>
Reviewed by:	markj
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D18876

There is may be only 11b channel (since chanflags[] table
maps MODE_AUTO to the corresponding 11b channel flags).

Checked with RTL8812AU, STA mode.

MFC after:	5 days

MFC after:	5 days

Change the way how channel list mode <-> desired mode match is done:
- Match channel list mode for next non-auto desired modes:
 * 11b: 11g, 11ng, 11acg;
 * 11a: 11na, 11ac
- Add pre-defined channels only when one of the next conditions met:
 * the desired channel mode is 'auto' or
 * the desired channel and selected channel list modes are exactly
the same or
 * the previous rule (11g / 11n / 11ac promotion) applies.

Before r275875 construction work properly for all except
11ng / 11na / 11acg / 11ac modes - these were broken at all
(i.e., the scan list was empty); after r275875 all checks were removed,
so scan table was populated by all device-compatible channels
(desired mode was ignored).

For example, if I will set 'ifconfig wlan0 mode 11ng' for RTL8821AU:
- pre-r275875: nothing, scan will not work;
- after r275875: both 11ng and 11na bands were scanned; also, since 11b
channel list was used, 14th channel was scanned too.
- after this change: only 11ng - 1-13 channels - are used for scanning.

Tested with:
 * RTL8188EE, STA mode.
 * RTL8821AU, STA mode.

MFC after:	5 days

While the warning is a false positive, it is possible to clarify the code by
always initializing the variable. This does also allow to make the sending
of the "beep" control sequence depend on the validity of its parameters.

I have left the redundant assignment of 0 to the now initialized variables
in place since this makes the code simpler to understand and does not add
any run-time overhead (the compiler completely removes the "else if" test
and the assignments).

There was an embedded literal escape character in a string, which messes up
diplaying the source code on a terminal that interprets ANSI sequences. The
literal escape has been replaced by \e (non-standard, but supported by all
relevant compilers, and already used in other source files in base).

MFC after:	2 weeks

According to systat(1) :only option is supposed to accept multiple drives
but the parser for its arguments stops after first entry. Fix the parser
logic to accept multiple drives.

PR:		59220
Reported by:	Andy Farkas <andyf@speednet.com.au>
MFC after:	1 week

Previously, we directly used libzfs_core's lzc_receive to import to a
temporary snapshot, then cloned the snapshot and setup the properties. This
failed when attempting to import replication streams with questionable
error.

libzfs's zfs_receive is a much better fit here, so we now use it instead
with the destination dataset and let libzfs take care of the dirty details.
be_import is greatly simplified as a result.

Reported by:	Marie Helene Kvello-Aune <freebsd@mhka.no>
MFC after:	1 week

Tested on HP AF006UR.

MFC after:	2 weeks

This is more compatible with formatting tools and looks more normal.

Reported by:	jhb (on a different review)
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D18442

While this is a false positive (a sufficiently large buffer has been
allocated in the line above), the use of strdup() simplifies and clarifies
the code.

MFC after:	2 weeks

Submitted by:	Sebastian Huber <sebastian.huber@embedded-brains.de>
MFC after:	3 days

MFC after:	1 week

amd64 miniport drivers are allowed to use FPU which triggers "Unregistered use
of FPU in kernel" panic.

Wrap all variants of MSCALL with fpu_kern_enter/fpu_kern_leave.  To reduce
amount of allocations/deallocations done via
fpu_kern_alloc_ctx/fpu_kern_free_ctx maintain cache of fpu_kern_ctx elements.

Based on the patch by Paul B Mahol

PR:		165622
Submitted by:	Vlad Movchan <vladislav.movchan@gmail.com>
MFC after:	1 month

Ensure that invalid sizes for DIOCGETSRCNODES do not cause panics.

MFC after:	 1 week

gsc_destroy() is no longer needed as of r343287.

MFC after:	1 week

psn_len is controlled by user space, but we allocated memory based on it.
Check how much memory we might need at most (i.e. how many source nodes we
have) and limit the allocation to that.

Reported by:	markj
MFC after:	1 week

It is done by net80211 since r319460.

MFC after:	24 days
X-MFC-With:	343094

Also, expose IFLIB_MAX_RX_SEGS to iflib drivers and add
iflib_dma_alloc_align() to the iflib API.

Performance is generally better with the tunable/sysctl
dev.vmx.<index>.iflib.tx_abdicate=1.

Reviewed by:	shurd
MFC after:	1 week
Relnotes:	yes
Sponsored by:	RG Nets
Differential Revision:	https://reviews.freebsd.org/D18761

iflib_device_register() and iflib_pseudo_register().

Reviewed by:	shurd
MFC after:	1 week
Sponsored by:	RG Nets
Differential Revision:	https://reviews.freebsd.org/D18760

The number of syscalls made during parsing of any config that
defines tables is also reduced, and incorrect warnings that HFSC
parent queue bandwidths were smaller than the sum of their child
bandwidths have been fixed.

Reviewed by:	kp
MFC after:	1 week
Sponsored by:	RG Nets
Differential Revision:	https://reviews.freebsd.org/D18759

Note that these interfaces are available only to root.

admbugs:	765
Reported by:	Vlad Tsyrklevich <vlad@tsyrklevich.net>
Reviewed by:	rmacklem
MFC after:	1 day
Security:	Kernel memory disclosure
Sponsored by:	The FreeBSD Foundation

Fix typos while here.

MFC after:	1 week
Sponsored by:	The FreeBSD Foundation

The existing copyin(9) and copyout(9) routines on RISC-V perform only a
simple byte-by-byte copy.  Improve their performance by performing
word-sized copies where possible.

Submitted by:	Mitchell Horne <mhorne063@gmail.com>
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D18851

No functional change intended.

Submitted by:	Mitchell Horne <mhorne063@gmail.com>
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D18850

Update r343122 to include -ALPHA, -BETA and -RC releases as
upgrade-able via freebsd-update.

PR:		234771
Submitted by:	Gerald Aryeetey <aryeeteygerald_rogers.com>
Reported by:	delphij, des
Reviewed by:	delphij
MFC with:	r343122
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D18881