There is no sense to keep that memory allocated during the flush.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#14855
After removing the -FreeBSD and -NetBSD, we're left with a nuber of
BSD-2-Clause AND BSD-2-Clause, so tidy that up.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
The SPDX folks have obsoleted the BSD-2-Clause-NetBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Should not cause functional changes.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#14854
When the special_small_blocks property is being set during a pool
create it enforces a limit of 128KiB even if the pool's record size
is larger.
If the recordsize property is being set during a pool create, then
use that value instead of the default SPA_OLD_MAXBLOCKSIZE value.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Don Brady <dev.fs.zfs@gmail.com>
Closes#13815Closes#14811
The auto_replace_001_pos test case does not reliably pass on
Fedora 37 and newer. Until the test case can be updated to make
it reliable add it to the list of "maybe" exceptions on Linux.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #14851Closes#14852
Fixes: ad9d10a859 ("efi: mark as broken on i386")
Fixes: bee3d4bf8e ("Move DIRDEPS_BUILD settings to sys.dirdeps.mk")
Sponsored by: The FreeBSD Foundation
Reduce the default log level for netlink to LOG_INFO. This removes a
number of messages such as
> [nl_iface] dump_sa: unsupported family: 0, skipping
or
> [nl_iface] get_operstate_ether: error calling SIOCGIFMEDIA on vlan0: 22
that are useful for debugging, but not for most users.
Reviewed by: melifaro
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D40062
Import BSD-3-Clause-Clear ath11k driver assumed to be
based on Linux kvalo/ath.git master at
6bae9de622d3ef4805aba40e763eb4b0975c4f6d.
Complement the driver to make compile on FreeBSD
using LinuxKPI with changes covered by #ifdef (__FreeBSD__).
Further select updates were applied since the initial import
in order to keep compiling along with other LinuxKPI based
drivers.
Add the module build framework but keep disconnected from the
build for now.
The current driver (or rather LinuxKPI) lacks support for some
"qcom" bits needed in order to get things working.
There was interest by various people to enhance support further.
We initially only plan to support PCI parts but it would be great
to further enhance qcom SoC support to run on several (cheap) APs.
The firmware is provided by port net/wifi-firmware-ath11k-kmod.
Given the lack of full license texts on most files this is
imported under the draft policy for handling SPDX files (D29226)
and with approval for BSD-3-Clause-Clear. [1]
Approved by: core (jhb, 2023-05-11) [1]
MFC after: 2 months
Add crypto/hash.h and a dummy kernel_connect() needed to compile
the ath11k wireless driver. While I hope we will not actually need
the hash.h fallbacks, kernel_connect() we will have to deal with once
we sort out more QMI bits.
MFC after: 10 days
pmap_get_pcid() calls zpcpu_get() which is defined in pcpu.h.
It is unclear why we do not include that header but like right
above the change add another guard around pmap_get_pcid().
This allows some LinuxKPI headers to compile again.
Suggested by: markj
MFC after: 10 days
Setting vlan flags needlessly takes the exclusive VLAN_XLOCK().
If we have stacked vlan devices (i.e. QinQ) and we set vlan flags (e.g.
IFF_PROMISC) we call rtnl_handle_ifevent() to send a notification about
the interface.
This ends up calling SIOCGIFMEDIA, which requires the VLAN_SLOCK().
Trying to take that one with the VLAN_XLOCK() held deadlocks us.
There's no need for the exclusive lock though, as we're only accessing
parent/trunk information, not modifying it, so a shared lock is
sufficient.
While here also add a test case for this issue.
Backtrace:
shared lock of (sx) vlan_sx @ /usr/src/sys/net/if_vlan.c:2192
while exclusively locked from /usr/src/sys/net/if_vlan.c:2307
panic: excl->share
cpuid = 29
time = 1683873033
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe015d4ad4b0
vpanic() at vpanic+0x152/frame 0xfffffe015d4ad500
panic() at panic+0x43/frame 0xfffffe015d4ad560
witness_checkorder() at witness_checkorder+0xcb5/frame 0xfffffe015d4ad720
_sx_slock_int() at _sx_slock_int+0x67/frame 0xfffffe015d4ad760
vlan_ioctl() at vlan_ioctl+0xf8/frame 0xfffffe015d4ad7c0
dump_iface() at dump_iface+0x12f/frame 0xfffffe015d4ad840
rtnl_handle_ifevent() at rtnl_handle_ifevent+0xab/frame 0xfffffe015d4ad8c0
if_setflag() at if_setflag+0xf6/frame 0xfffffe015d4ad930
ifpromisc() at ifpromisc+0x2a/frame 0xfffffe015d4ad960
vlan_setflags() at vlan_setflags+0x60/frame 0xfffffe015d4ad990
vlan_ioctl() at vlan_ioctl+0x216/frame 0xfffffe015d4ad9f0
if_setflag() at if_setflag+0xe4/frame 0xfffffe015d4ada60
ifpromisc() at ifpromisc+0x2a/frame 0xfffffe015d4ada90
bridge_ioctl_add() at bridge_ioctl_add+0x499/frame 0xfffffe015d4adb10
bridge_ioctl() at bridge_ioctl+0x328/frame 0xfffffe015d4adbc0
ifioctl() at ifioctl+0x972/frame 0xfffffe015d4adcc0
kern_ioctl() at kern_ioctl+0x1fe/frame 0xfffffe015d4add30
sys_ioctl() at sys_ioctl+0x154/frame 0xfffffe015d4ade00
amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe015d4adf30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe015d4adf30
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x22b0f0ef8d8a, rsp = 0x22b0ec63f2c8, rbp = 0x22b0ec63f380 ---
KDB: enter: panic
[ thread pid 5715 tid 101132 ]
Sponsored by: Rubicon Communications, LLC ("Netgate")
Those definitions are required for the GVT-d emulation to parse the
OpRegion.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40037
Intel GPUs have two special memory regions. They are called Graphics
Stolen Memory and OpRegion. bhyve has to emulate both of them. In order
to keep track of those special regions, add generic mmio ranges to the
passthru emulation.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40036
The GVT-d emulation tries to allocate some specific memory. It could
happen that this address doesn't exist. In that case, GVT-d will fall
back to allocate any address. Nevertheless, this only works if the e820
fails with an error instead of exiting on an assertion.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D40034
When originally implemented, there was no distinction between
DIRDEPS_BUILD and META_MODE, they were one and the same.
META_MODE however is useful by itself, but since meta.sys.mk
had lots of settings related to DIRDEPS_BUILD its use was limited
to DIRDEPS_BUILD.
Move (most) DIRDEPS_BUILD related items to sys.dirdeps.mk
so that meta.sys.mk can be used for just META_MODE.
There is of course some bluring of the lines, so settings remain
in meta.sys.mk
Add MK_META_ERROR_TARGET to enable the META_MODE .ERROR target
independent of DIRDEPS_BUILD, it copies failed .meta files to ${SB}/error
to make it easier to identify the cause of build failures.
Since sys.dirdeps.mk should be included first, most of
local.meta.sys.mk becomes local.sys.dirdeps.mk
and some other bits need to move to local.sys.dirdeps.env.mk
Also fix dirdeps.mk to not add CURDIR to DIRDEPS when it is SRCTOP.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D40053
The dmu_buf_is_dirty() call doesn't make sense here for two reasons:
1. txg is 0 for unassigned tx, so it was a no-op.
2. It is equivalent of checking if we have dirty records and we are doing
this few lines earlier.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Pawel Jakub Dawidek <pawel@dawidek.net>
Closes#14825
I don't know an easy way to shrink down dbuf size, so just deny block cloning
into dbufs that don't match our BP's size.
This fixes the following situation:
1. Create a small file, eg. 1kB of random bytes. Its dbuf will be 1kB.
2. Create a larger file, eg. 2kB of random bytes. Its dbuf will be 2kB.
3. Truncate the large file to 0. Its dbuf will remain 2kB.
4. Clone the small file into the large file. Small file's BP lsize is
1kB, but the large file's dbuf is 2kB.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Pawel Jakub Dawidek <pawel@dawidek.net>
Closes#14825
Reimplement some of the block cloning vs dbuf logic, mostly to fix
situation where we clone a block and in the same transaction group
we want to partially overwrite the clone.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Pawel Jakub Dawidek <pawel@dawidek.net>
Closes#14825
> The SSL_library_init() and OpenSSL_add_ssl_algorithms() functions were
> deprecated in OpenSSL 1.1.0 by OPENSSL_init_ssl().
and
> The ERR_load_crypto_strings(), SSL_load_error_strings(), and
> ERR_free_strings() functions were deprecated in OpenSSL 1.1.0 by
> OPENSSL_init_crypto() and OPENSSL_init_ssl() and should not be used.
Reviewed by: ngie
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40065
Fix the sizing of IEEE80211_TX_INFO_DRIVER_DATA_SIZE so that it
also works on 32bit platforms. Otherwise it triggers a compile-time
assertion in ath10k for i386.
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
At least for RAIDZ zio_shrink() does not reduce zio size, but reduced
wsz in that case likely results in writing uninitialized memory.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#14853
Remove the i386 ifdefs and files. It never worked.
Sponsored by: Netflix
Reviewed by: manu, tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D40012
We're never going to support EFI booting on i386 (32-bit). Start to
decommission it, since it's never worked.
Sponsored by: Netflix
Reviewed by: tsoome, emaste
Differential Revision: https://reviews.freebsd.org/D40011
Only set the baudrate when it is different than what the device has
reported. In addition, pass in the args to effect no change to the other
parameters to the serial port. Some EFI firmware gets cranky when you
set them to the same value, so avoid doing so (we likely can remove the
HyperV workaround with this fix, but I kept it in place). Add comments
to the code for why we do this too.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D40010
Remove rtsdtr_off. It's basically unused. Expand its meaning, but put
changing flow control to under an ifdef. We shouldn't set it unless
we're sure we need to do so. UEFI normally initializes the device
correctly, and we should avoid needless changes that aren't user
requested.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D40009
Rename efiserialc to eficom.c and move it to libefi. Remove
loader.efi.h, since it's not needed. It's architecture independent
(though how we use it might vary). Drivers also belong in libfoo
in the boot loader: all the BIOS drivers are in i386/libi386 and
the console driver is in efi/libefi.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D40007
Add a compat shim for the "comconsole" name so that people with a
"console=comconsole" in their loader.conf on aarch64 will continue to
work (though with a warning).
This is only aarch64: it will never be there for amd64 (where comconsole
always means talk to the hardware directly). To do that is too hard.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39983
Fix the 'renaming kludge' that we absolutely cannot do going forward
(it's cost us days of engineering time).
console=comconsole talks to the hardware directly. This is available
only on amd64. It is not available anywhere else (and so requires
changes for people doing comconsole on aarch64)
console=eficom talks to the console via EFI protocols. It's available
on amd64, aarch64 and riscv64. It's the first port that we find, though
it can be overriden by efi_com_port (which should be set to the UID of
the serial port, not the I/O port, despite the name). devinfo -v
will give the UID to uartX mapping.
This is an incompatible change for HYPER-V on amd64. It only works with
eficom console, so you'll need to change your configuration in
loader.conf. No compatibility hack will ever be provided for this (since
it requires renamig, which the loader cannot reliably do).
It's also an incompatible change for aarch64. comconsole will need to
change to eficom. There might be a comconsole "shim" for this.
All the interlock to keep only eficom and comconsole from both attaching
have been removed.
RelNotes: Yes
Sponsored by: Netflix
Discussed with: kevans
Differential Revision: https://reviews.freebsd.org/D39982
Much like casueword*, except just a plain old swap. Maintains a similar
interface to casu(9)- return value -1 (fault), 0 (success), or 1 (fail),
and also both ll/sc and LSE variants are implemented.
These will be used to implement 32-bit swp/swpb emulation on aarch64.
Reveiwed by: andrew
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D39837