r343376 kevans Jan. 24, 2019, 3:42 a.m.
* There is (almost) nothing to do in suspend/resume if if_iwm has failed
during initialization (e.g. because of firmware load failure) and was
already uninitialized by iwm_detach_local().

Submitted by:	Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from:	DragonFlyBSD (67b5e090efb225654815fed91020db6cfc16bb19)
r343375 kevans Jan. 24, 2019, 3:42 a.m.
* We should load the firmware exactly once before the driver really
initializes the hardware the first time, and unload it at detach time.
There is no need to retrieve the firmware during execution of
iwm_mvm_load_ucode_wait_alive(), we should make sure we already have the
firmware data at hand before that.

* The existing sc_preinit_hook code fails to deal with the case where
if_iwm is loaded by the loader (or is statically linked) and the
firmware needs to be loaded from disk. So we can just call
iwm_read_firmware() from iwm_attach() directly.

* A separate solution will have to be added to properly defer the firmware
loading during bootup, until the necessary filesystem is mounted.

Submitted by:	Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from:	DragonFlyBSD (0104ee1f4cb6a2313c00c2526c6ae98d42e5041d)
r343374 kevans Jan. 24, 2019, 3:41 a.m.
* Doing the iwm_prepare_card_hw() call in iwm_attach() only on Family 8000
hardware matches the code in Linux iwlwifi.

* While there remove DEFAULT_MAX_TX_POWER definition which is unused, and
has a value different from IWL_DEFAULT_MAX_TX_POWER in iwlwifi.

Submitted by:	Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from:	DragonFlyBSD (e8560f8dc58df12a7c79a6bb4e6ccb156e001085)
r343373 kevans Jan. 24, 2019, 3:41 a.m.
* Rather than providing a non-zero index into the firmware RS table,
we should always use index 0 and update the firmware RS table whenever
our chosen tx rate for data-frames changes.

* Send IWM_LQ_CMD updates when the tx rate gets updated by the net80211
rate control (which is after we tell the tx status to the net80211
rate-control in iwm_mvm_rx_tx_cmd_single()).

* Disregard frames transferred with a different tx rate than the currently
selected rate for the rate-control calculations. This way we avoid
counting management frames (which are sent at a slow, and fixed rate),
as well as frames we added to the tx queue just before a new IWM_LQ_CMD
update took effect.

Submitted by:	Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from:	DragonFlyBSD (5d6b465e288ac5b52d7115688d4e6516acbbea1c)
r343372 erj Jan. 24, 2019, 1:08 a.m.
From Krzysztof:

Ensure that the entire data buffer passed from the NVM update tool is copied in
to kernel space and copied back out to user space using copyin() and copyout().

PR:		234104
Submitted by:	Krzysztof Galazka <krzysztof.galazka@intel.com>
Reported by:	Finn <ixbug@riseup.net>
MFC after:	5 days
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D18817
r343369 erj Jan. 24, 2019, 1:03 a.m.
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
r343368 ngie Jan. 23, 2019, 11:48 p.m.
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
r343367 ngie Jan. 23, 2019, 11:30 p.m.
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
r343366 brooks Jan. 23, 2019, 11:25 p.m.
This was a tangential change submitted as part of D18930.

Submitted by:	jack@gandi.net
r343365 ngie Jan. 23, 2019, 11:06 p.m.
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

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
r343364 markj Jan. 23, 2019, 10:19 p.m.
Reviewed by:	bz
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation
r343363 markj Jan. 23, 2019, 10:18 p.m.
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
r343362 ngie Jan. 23, 2019, 10 p.m.
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):


instead of:


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
r343354 markj Jan. 23, 2019, 8:02 p.m.
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
r343353 markj Jan. 23, 2019, 6:58 p.m.
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