Roger Pau Monné [Wed, 25 Nov 2020 11:34:38 +0000 (12:34 +0100)]
xen: allow limiting the amount of duplicated pending xenstore watches
Xenstore watches received are queued in a list and processed in a
deferred thread. Such queuing was done without any checking, so a
guest could potentially trigger a resource starvation against the
FreeBSD kernel if such kernel is watching any user-controlled xenstore
path.
Allowing limiting the amount of pending events a watch can accumulate
to prevent a remote guest from triggering this resource starvation
issue.
For the PV device backends and frontends this limitation is only
applied to the other end /state node, which is limited to 1 pending
event, the rest of the watched paths can still have unlimited pending
watches because they are either local or controlled by a privileged
domain.
The xenstore user-space device gets special treatment as it's not
possible for the kernel to know whether the paths being watched by
user-space processes are controlled by a guest domain. For this reason
watches set by the xenstore user-space device are limited to 1000
pending events. Note this can be modified using the
max_pending_watch_events sysctl of the device.
This is XSA-349.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Mark Johnston [Sun, 3 Jan 2021 16:32:30 +0000 (11:32 -0500)]
Ensure that dirent's d_off field is initialized
We have the d_off field in struct dirent for providing the seek offset
of the next directory entry. Several filesystems were not initializing
the field, which ends up being copied out to userland.
Kristof Provost [Mon, 18 Jan 2021 21:55:53 +0000 (16:55 -0500)]
MFC r368237: if: Fix panic when destroying vnet and epair simultaneously
When destroying a vnet and an epair (with one end in the vnet) we often
panicked. This was the result of the destruction of the epair, which destroys
both ends simultaneously, happening while vnet_if_return() was moving the
struct ifnet to its home vnet. This can result in a freed ifnet being re-added
to the home vnet V_ifnet list. That in turn panics the next time the ifnet is
used.
Prevent this race by ensuring that vnet_if_return() cannot run at the same time
as if_detach() or epair_clone_destroy().
Ed Maste [Wed, 29 Apr 2020 18:51:34 +0000 (18:51 +0000)]
MF10 r352637,r358076: correct Clang and lld version checks
r352637 (mhorne): Allow for compiler versions >= 10
r358076 (dim): Correctly recognize linker versions greater than 10.0.
These routines determine the host compiler and linker version, and caused
attempts to build 12.1-RELEASE on 13-CURRENT to fail after the latter was
updated to Clang 10. We don't guarantee such a build config to work, but
it is used by FreeBSD ports build processes. As a result the fixes from
stable/12 will be included with the next set of advisories, and are being
committed to the branch now to unblock ports builds.
PR: 245973
Reported by: sbruno, antoine
Approved by: so
Errata: EN-20:10.build
Sponsored by: The FreeBSD Foundation
Michael Tuexen [Fri, 25 Oct 2019 18:46:53 +0000 (18:46 +0000)]
MFS r354090:
Ensure that the flags indicating IPv4/IPv6 are not changed by failing
bind() calls. This would lead to inconsistent state resulting in a panic.
A fix for stable/11 was committed in
https://svnweb.freebsd.org/base?view=revision&revision=338986
Reported by: syzbot+2609a378d89264ff5a42@syzkaller.appspotmail.com
Obtained from: jtl@
Sponsored by: Netflix, Inc.
Approved by: re (gjb@)
Glen Barber [Fri, 18 Oct 2019 00:00:11 +0000 (00:00 +0000)]
- Update releng/12.1 from RC1 to RC2 as part of the 12.1-RELEASE
cycle.
- Update the dvd1.iso pkg(8) configuration to use the release_1
package set to populate the dvd.
Approved by: re (implicit)
Sponsored by: Rubicon Communications, LLC (Netgate)
Ian Lepore [Thu, 17 Oct 2019 16:20:24 +0000 (16:20 +0000)]
MFC r353675 from stable-12 (r353651-r353652 from head)...
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.
Michael Tuexen [Tue, 15 Oct 2019 16:05:55 +0000 (16:05 +0000)]
MFS r353563:
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:
The ioalign property does define the alignment of data buffer.
If the alignment is required and our buffer is not aligned, or if
the data buffer is not multiple of Blocksize, we need to use bounce buffer
to perform the block IO. This is much like with BIOS version, except
there the INT13 needs buffer to be located in low memory.
Michael Tuexen [Thu, 10 Oct 2019 18:39:11 +0000 (18:39 +0000)]
MFS r353402:
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
Reviewed by: bcr@
Approved by: re (gjb@)
Glen Barber [Thu, 10 Oct 2019 18:27:05 +0000 (18:27 +0000)]
MFS r353409:
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.
Approved by: re (kib)
Sponsored by: Rubicon Communications, LLC (Netgate)
Michael Tuexen [Thu, 10 Oct 2019 18:19:22 +0000 (18:19 +0000)]
MFS r353395:
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
MFS r353396:
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
MFS r353397:
When skipping the address parameter, take the padding into account.
MFS r353398:
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
MFS r353399:
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
MFS r353400:
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
MFS r353401:
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
MFS r353403:
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
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
Approved by: re (gjb)
MFS r353177:
Add quirk for XHCI(4) controllers to support USB control transfers
above 1Kbyte. It might look like some XHCI(4) controllers do not
support when the USB control transfer is split using a link TRB. The
next NORMAL TRB after the link TRB is simply failing with XHCI error
code 4. The quirk ensures we allocate a 64Kbyte buffer so that the
data stage TRB is not broken with a link TRB.
Found at: EuroBSDcon 2019
Sponsored by: Mellanox Technologies
Approved by: re (gjb)
MFS r353173:
Increase the maximum user-space buffer size from 256kBytes to 32MBytes for
libusb. This is useful for speeding up large data transfers while reducing
the interrupt rate.
Found at: EuroBSDcon 2019
Sponsored by: Mellanox Technologies
Approved by: re (gjb)
MFC r352957:
Update warning and error print formats in mlx5ib.
MFC r352958:
Make sure the number of IRQ vectors doesn't exceed 256 in mlx5core.
The "intr" field in "struct mlx5_ifc_eqc_bits" is only 8 bits wide.
MFC r352959:
Check return value of mlx5_vector2eqn() function in mlx5en.
MFC r352960:
Fix for missing cleanup code in error case in mlx5en.
MFC r352961:
Implement macro for asserting priv lock in mlx5en.
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.
MFC r352963:
Cleanup naming of IRQ vectors in mlx5en.
Remove unused IRQ naming functions and arrays.
MFC r352964:
Export channel IRQ number as part of the "hw_ctx_debug" sysctl(8) in mlx5en(4).
MFC r352965:
Correct and update some counter names in mlx5en(4).
MFC r352966:
Add port module event software counters in mlx5core.
While at it, fixup PME based on latest PRM defines.
MFC r352967:
Make the mlx5_vsc_wait_on_flag(9) function global.
MFC r352968:
Move mlx5_ifc_vsc_space_bits and mlx5_ifc_vsc_addr_bits to mlx5_ifc.h.
MFC r352969:
Use the MLX5_VSC_DOMAIN_SEMAPHORES constant instead of hand-rolled symbol
in mlx5core.
MFC r352970:
Define MLX5_VSC_DOMAIN_SCAN_CRSPACE.
MFC r352971:
Read rege map from crdump scan space in mlx5core.
MFC r352972:
Remove no longer needed fwdump register tables from mlx5core.
MFC r352973:
Add missing blank line at the end of the print in mlx5core.
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 r352975:
Unify prints in mlx5core.
All prints in mlx5core should use on of the macros:
mlx5_core_err/dbg/warn
MFC r352976:
Unify prints in mlx5en(4).
All prints in mlx5en(4) should use on of the macros:
mlx5_en_err/dbg/warn
MFC r352977:
Sort the ports registers definitions numerically in mlx5core.
MFC r352978:
Add definition for the Port Buffer Status Register in mlx5core.
MFC r352979:
Update definitons for PPTB and PBMC registers layouts in mlx5core.
MFC r352980:
Add mlx5e_dbg() compatibility macro.
MFC r352981:
Import Linux code to query/set buffer state in mlx5en(4).
MFC r352982:
Add support for buffer parameter manipulations in mlx5en(4).
The following sysctls are added:
dev.mce.N.conf.qos.cable_length
dev.mce.N.conf.qos.buffers_size
dev.mce.N.conf.qos.buffers_prio
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 r352984:
Add the ability to query the EEPROM information in mlx5tool(8).
MFC r352985:
Add sysctl(8) to get and set forward error correction, FEC, configuration
in mlx5en(4).
MFC r352986:
Return an error from ioctl(MLX5_FW_RESET) if reset was rejected in mlx5core.
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 r352988:
Remove unused cpu field from channel structure in mlx5en(4).
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 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.
MFS r353182:
Make sure the transmit loop doesn't get starved in ipoib.
When the software send queue gets filled up, callbacks to
if_transmit will stop. Make sure the transmit callback
routine checks the send queue and outputs any remaining
mbufs. Else the remaining mbufs may simply sit in the
output queue blocking the transmit path.
Sponsored by: Mellanox Technologies
Approved by: re (gjb)
Kyle Evans [Mon, 7 Oct 2019 02:57:00 +0000 (02:57 +0000)]
MFS r353157: tuntap(4): loosen up tunclose restrictions
Realistically, this cannot work. We don't allow the tun to be opened twice,
so it must be done via fd passing, fork, dup, some mechanism like these.
Applications demonstrably do not enforce strict ordering when they're
handing off tun devices, so the parent closing before the child will easily
leave the tun/tap device in a bad state where it can't be destroyed and a
confused user because they did nothing wrong.
Concede that we can't leave the tun/tap device in this kind of state because
of software not playing the TUNSIFPID game, but it is still good to find and
fix this kind of thing to keep ifconfig(8) up-to-date and help ensure good
discipline in tun handling.
Andrew Turner [Fri, 4 Oct 2019 14:10:56 +0000 (14:10 +0000)]
MFS r353032:
Check the vfs option length is valid before accessing through
When a VFS option passed to nmount is present but NULL the kernel will
place an empty option in its internal list. This will have a NULL
pointer and a length of 0. When we come to read one of these the kernel
will try to load from the last address of virtual memory. This is
normally invalid so will fault resulting in a kernel panic.
Fix this by checking if the length is valid before dereferencing.
Dimitry Andric [Thu, 3 Oct 2019 16:22:56 +0000 (16:22 +0000)]
Merge r353031 from stable/12:
Pull in r357528 from upstream llvm trunk (by Craig Topper):
[X86] Check MI.isConvertibleTo3Addr() before calling
convertToThreeAddress in X86FixupLEAs.
X86FixupLEAs just assumes convertToThreeAddress will return nullptr
for any instruction that isn't convertible.
But the code in convertToThreeAddress for X86 assumes that any
instruction coming in has at least 2 operands and that the second one
is a register. But those properties aren't guaranteed of all
instructions. We should check the instruction property first.
Pull in r365720 from upstream llvm trunk (by Craig Topper):
[X86] Don't convert 8 or 16 bit ADDs to LEAs on Atom in FixupLEAPass.
We use the functions that convert to three address to do the
conversion, but changing an 8 or 16 bit will cause it to create a
virtual register. This can't be done after register allocation where
this pass runs.
I've switched the pass completely to a white list of instructions
that can be converted to LEA instead of a blacklist that was
incorrect. This will avoid surprises if we enhance the three address
conversion function to include additional instructions in the future.
Fixes PR42565.
This should fix assertions/segfaults when compiling certain ports with
CPUTYPE=atom.
Glen Barber [Thu, 3 Oct 2019 14:41:20 +0000 (14:41 +0000)]
MFS12 r353047:
MFC r353004, r353012:
r353004:
Explicitly add opensolaris_load="YES" to loader.conf through the
installer when installing the system on a ZFS root filesystem.
For arm64, zfs_load="YES" does not add opensolaris.ko as a kld
dependency, so add it explicitly to prevent boot-time failures
out-of-box.
r353012:
Add a comment explaining why the opensolaris_load line in loader.conf
is explicitly added.
projects / FreeBSD / FreeBSD.git / log