MFC r353545:
Explicitly initialize the memory buffer to store O_ICMP6TYPE opcode.
By default next_cmd() initializes only first u32 of opcode. O_ICMP6TYPE
opcode has array of bit masks to store corresponding ICMPv6 types.
An opcode that precedes O_ICMP6TYPE, e.g. O_IP6_DST, can have variable
length and during opcode filling it can modify memory that will be used
by O_ICMP6TYPE opcode. Without explicit initialization this leads to
creation of wrong opcode.
Reported by: Boris N. Lytochkin
Obtained from: Yandex LLC
Kristof Provost [Fri, 18 Oct 2019 03:38:01 +0000 (03:38 +0000)]
MFC r353443
mountroot: run statfs after mounting devfs
The usual flow for mounting a file system is to VFS_MOUNT() and then
immediately VFS_STATFS().
That's not done in vfs_mountroot_devfs(), which means the
mp->mnt_stat.f_iosize field is not correctly populated, which in turn
causes us to mark valid aio operations as unsafe (because the io size is
set to 0), ultimately causing the aio_test:md_waitcomplete test to fail.
John Baldwin [Thu, 17 Oct 2019 23:29:52 +0000 (23:29 +0000)]
MFC 348779:
Keep the shadow PCIR_COMMAND synced with the real one for pass through.
This ensures that bhyve properly recognizes when decoding is disabled
for BARs on passthru devices. To properly handle writes to the
register, export a pci_emul_cmd_changed function from pci_emul.c that
the pass through device model invokes for config writes that change
PCIR_COMMAND.
John Baldwin [Thu, 17 Oct 2019 23:26:39 +0000 (23:26 +0000)]
MFC 348778,348998: Enable memory and I/O decoding in PCI devices on demand.
348778:
Enable memory and I/O decoding in PCI devices on demand.
Rather than uncoditionally setting the MEMEN and PORTEN bits in
PCIR_COMMAND for PCI devices, set the respective bit when the first
BAR of a given type is added to the device. This more closely matches
what firmware does on bare metal.
BUSMASTEREN is still set unconditionally. Eventually this bit should
move into the device models as not all device models need this set.
348998:
Remove a spurious break when setting up a 64-bit memory BAR.
This was causing 'enbit' to not be initialized in this case.
John Baldwin [Thu, 17 Oct 2019 23:17:56 +0000 (23:17 +0000)]
MFC 348212,348712: Add support for writing to guest memory in the debug server.
348212:
Add support for writing to guest memory in the debug server.
- Add a write_mem counterpart to read_mem to handle writes to MMIO.
- Add support for the GDB 'M' packet to write bytes to the guest's
memory. For MMIO writes, attempt to batch writes up into words.
This is imprecise, but if you write a single 2 or 4-byte aligned
word, it should be treated as a single MMIO write operation.
- While here, tidy up the parsing of the 'm' command used for reading
memory to match 'M'.
348712:
Use parse_integer to avoid sign extension.
Coverity warned about gdb_write_mem sign extending the result of
parse_byte shifted left by 24 bits when generating a 32-bit memory
write value for MMIO. Simplify the code by using parse_integer
instead of unrolled parse_byte calls.
Ian Lepore [Thu, 17 Oct 2019 01:30:37 +0000 (01:30 +0000)]
MFC r353651-r353652
r353651:
Relax the sdhci(4) check that filters out the 1.8v voltage option unless
the slot is flagged as 'embedded'.
The features related to embedded and shared slots were added in v3.0 of
the sdhci spec. Hardware prior to v3 sometimes supported 1.8v on non-
removable devices in embedded systems, but had no way to indicate that
via the standard sdhci registers (instead they use out of band metadata
such as FDT data).
This change adds the controller specification version to the check for
whether to filter out the 1.8v selection. On older hardware, the 1.8v
option is allowed to remain. On 3.0 or later it still requires the
embedded-slot flag to remain.
This is part of the fix for PR 241301 (eMMC not detected on Beaglebone).
Changes to the sdhci_ti driver are also needed for a full fix.
PR: 241301
r353652:
Revert r351218 (by manu). While the changes in r351218 appear to be (and
should be) correct, they lead to the eMMC on a Beaglebone failing to work
in some situations.
The TI sdhci hardware is kind of strange. The first device inherently
supports 1.8v and 3.3v and the abililty to switch between them, and the
other two devices must be set to 1.8v in the sdhci power control register to
operate correctly, but doing so actually makes them run at 3.3v (unless an
external level-shifter is present in the signal path). Even the 1.8v on the
first device may actually be 3.3v (or any other value), depending on what
voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip.
Another strange quirk is that the convention for am335x sdhci drivers in
linux and uboot and the am335x boot ROM seems to be to set the voltage in
the sdhci capabilities register to 3.0v even though the actual voltage is
3.3v. Why this is done is a complete mystery to me, but it seems to be
required for correct operation.
If we had complete modern support for the am335x chip we could get the
actual voltages from the FDT data and the regulator framework. But our
am335x code currently doesn't have any regulator framework support.
Reverting to the prior code will get the popular Beaglebone boards working
again.
This is part of the fix for PR 241301, but also requires r353651 for a
complete fix.
Brooks Davis [Tue, 15 Oct 2019 20:08:19 +0000 (20:08 +0000)]
MFC r353329:
msun: Silence new harmless -Wimplicit-int-float-conversion warnings
Clang from trunk recently added a warning for when implicit int-to-float
conversions cause a loss of precision. The code in question is designed
to be able to handle that, so add explicit casts to silence this.
Submitted by: James Clarke <jrtc27@jrtc27.com>
Reviewed by: dim
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21913
Alexander Motin [Tue, 15 Oct 2019 18:44:28 +0000 (18:44 +0000)]
MFC r352939: Improve latency of synchronous 128KB writes.
Before my ZIL space optimization few years ago 128KB writes were logged
as two 64KB+ records in two 128KB log blocks. After that change it became
~124KB+/4KB+ in two 128KB log blocks to free space in the second block
for another record. Unfortunately in case of 128KB only writes, when space
in the second block remained unused, that change increased write latency by
imbalancing checksum computation time between parallel threads.
This change introduces new 68KB log block size, used for both writes below
67KB and 128KB-sharp writes. Writes of 68-127KB are still using one 128KB
block to not increase processing overhead. Writes above 131KB are still
using full 128KB blocks, since possible saving there is small. Mixed loads
will likely also fall back to previous 128KB, since code uses maximum of
the last 10 requested block sizes.
On a simple 128KB write test with queue depth of 1 this change demonstrates
~15-20% performance improvement.
Alexander Motin [Tue, 15 Oct 2019 18:39:32 +0000 (18:39 +0000)]
MFC r352787: Replace argument checks with assertions.
Those functions are used by kernel, and we can't check all possible argument
errors in production kernel. Plus according to docs many of those errors
are checked by hardware. Assertions should just help with code debugging.
Brooks Davis [Tue, 15 Oct 2019 17:30:12 +0000 (17:30 +0000)]
MFC r353326:
Fix various -Wpointer-compare warnings
This warning (comparing a pointer against a zero character literal
rather than NULL) has existed since GCC 7.1.0, and was recently added to
Clang trunk.
Almost all of these are harmless, except for fwcontrol's str2node, which
needs to both guard against dereferencing a NULL pointer (though in
practice it appears none of the callers will ever pass one in), as well
as ensure it doesn't parse the empty string as node 0 due to strtol's
awkward interface.
Michael Tuexen [Tue, 15 Oct 2019 14:48:00 +0000 (14:48 +0000)]
MFC r353452:
Ensure that local variables are reset to their initial value when
dealing with error cases in a loop over all remote addresses.
This issue was found and reported by OSS_Fuzz in:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18080
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18086
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18121
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18163
Glen Barber [Thu, 10 Oct 2019 17:29:47 +0000 (17:29 +0000)]
MFC r353320:
Rework the logic for installing the pkg(8) configuration.
'quarterly' package sets do not exist for head, so explicitly
install the 'latest' configuration file there. Otherwise,
fall back to the original conditional evaluation to determine
if the 'latest' or 'quarterly' configuration file should be
installed.
As noted by the commit message, callouts are now persistant
and should not be in the auto-zero section of the RQ's and SQ's.
This fixes an assert when using the TX completion event
factor feature with mlx5en(4).
Found by: gallatin@
Sponsored by: Mellanox Technologies
Michael Tuexen [Thu, 10 Oct 2019 14:56:29 +0000 (14:56 +0000)]
MFC r353303:
Validate length before use it, not vice versa.
r353060 should have contained this...
This fixes
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18070
Michael Tuexen [Thu, 10 Oct 2019 14:54:22 +0000 (14:54 +0000)]
MFC r353290:
In r343587 a simple port filter as sysctl tunable was added to siftr.
The new sysctl was not added to the siftr.4 man page at the time.
This updates the man page, and removes one left over trailing whitespace.
Submitted by: Richard Scheffenegger
Differential Revision: https://reviews.freebsd.org/D21619
Michael Tuexen [Thu, 10 Oct 2019 14:52:48 +0000 (14:52 +0000)]
MFC r353145:
Plumb an mbuf leak in a code path that should not be taken. Also avoid
that this path is taken by setting the tail pointer correctly.
There is still bug related to handling unordered unfragmented messages
which were delayed in deferred handling.
This issue was found by OSS-Fuzz testing the usrsctp stack and reported
in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17794
Michael Tuexen [Thu, 10 Oct 2019 14:51:38 +0000 (14:51 +0000)]
MFC r353123:
Fix a use after free bug when removing remote addresses.
This bug was found by OSS-Fuzz and reported in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18004
Michael Tuexen [Thu, 10 Oct 2019 14:50:44 +0000 (14:50 +0000)]
MFC r353122:
Plumb an mbuf leak found by Mark Wodrich from Google by fuzz testing the
userland stack and reporting it in:
https://github.com/sctplab/usrsctp/issues/396
Michael Tuexen [Thu, 10 Oct 2019 14:49:49 +0000 (14:49 +0000)]
MFC r353119:
Fix the adding of padding to COOKIE-ECHO chunks.
Thanks to Mark Wodrich who found this issue while fuzz testing the
usrsctp stack and reported the issue in
https://github.com/sctplab/usrsctp/issues/382
Michael Tuexen [Thu, 10 Oct 2019 14:47:39 +0000 (14:47 +0000)]
MFC r353069:
Cleanup sctp_asconf_error_response() and ensure that the parameter
is padded as required. This fixes the followig bug reported by
OSS-Fuzz for the usersctp stack:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17790
Michael Tuexen [Thu, 10 Oct 2019 14:45:59 +0000 (14:45 +0000)]
MFC r353060:
Add missing input validation. This could result in reading from
uninitialized memory.
The issue was found by OSS-Fuzz for usrsctp and reported in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17780
Martin Matuska [Wed, 9 Oct 2019 22:18:01 +0000 (22:18 +0000)]
MFC r352732:
Sync libarchive with vendor.
Relevant vendor changes:
Issue #1237: Fix integer overflow in archive_read_support_filter_lz4.c
PR #1249: Correct some typographical and grammatical errors.
PR #1250: Minor corrections to the formatting of manual pages
Ed Maste [Wed, 9 Oct 2019 14:35:09 +0000 (14:35 +0000)]
MFC r353021: simplify path handling in sysctl_try_reclaim_vnode
MAXPATHLEN / PATH_MAX includes space for the terminating NUL, and namei
verifies the presence of the NUL. Thus there is no need to increase the
buffer size here.
The sysctl passes the string excluding the NUL, so req->newlen equal to
PATH_MAX is too long.
Andriy Gapon [Wed, 9 Oct 2019 09:40:03 +0000 (09:40 +0000)]
MFC r352591: MFZoL: Retire send space estimation via ZFS_IOC_SEND
Add a small wrapper around libzfs_core's lzc_send_space() to libzfs so
that every legacy ZFS_IOC_SEND consumer, along with their userland
counterpart estimate_ioctl(), can leverage ZFS_IOC_SEND_SPACE to
request send space estimation.
The legacy functionality in zfs_ioc_send() is left untouched for
compatibility purposes.
John Baldwin [Mon, 7 Oct 2019 20:41:55 +0000 (20:41 +0000)]
MFC 351557: Adjust the deprecated warnings for /dev/crypto to be less noisy.
Warn when actual operations are performed instead of when sessions are
created. The /dev/crypto engine in OpenSSL 1.0.x tries to create
sessions for all possible algorithms each time it is initialized
resulting in spurious warnings.
MFC r352991 and 353000:
Wait for FW readiness before initializing command interface in mlx5core.
Before attempting to initialize the command interface we must wait till
the fw_initializing bit is clear.
If we fail to meet this condition the hardware will drop our
configuration, specifically the descriptors page address. This scenario
can happen when the firmware is still executing an FLR flow and did not
finish yet so the driver needs to wait for that to finish.
MFC r352989:
Seal transmit path with regards to using destroyed mutex in mlx5en(4).
It may happen during link down that the running state may be observed
non-zero in the transmit routine, right before the running state is
cleared. This may end up using a destroyed mutex.
Make all channel mutexes and callouts persistant.
Preserve receive and send queue statistics during link toggle.
MFC r352987:
Remove mkey_be from channel structure in mlx5en(4).
Use value from priv structure instead.
This saves some space in the channel structure.
MFC r352983 and r353001:
Move EEPROM information query from a sysctl in mlx5en(4) to an ioctl
in mlx5core. The EEPROM information is not only a property of the
mlx5en(4) driver.
MFC r352974:
Add proper print in case of 0x0 health syndrome in mlx5core.
In case of health counter fails to increment it indicates a bad device health.
In case when the syndrome indicated by firmware is 0x0, this indicates that
firmware is unable to respond to initialization segment reads.
Add proper print in this case.
MFC r352962:
Add support for Multi-Physical Function Switch, MPFS, in mlx5en.
MPFS is a logical switch in the Mellanox device which forward packets
based on a hardware driven L2 address table, to one or more physical-
or virtual- functions. The physical- or virtual- function is required
to tell the MPFS by using the MPFS firmware commands, which unicast
MAC addresses it is requesting from the physical port's traffic.
Broadcast and multicast traffic however, is copied to all listening
physical- and virtual- functions and does not need a rule in the MPFS
switching table.