For someone new to the release bits it's not always clear what files are
being created. Report the disk image name explicitly.
Reviewed by: gjb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39953
The previous change involved calling check_cgmagic() twice in a row
for the same CG in order to differentiate when the CG was already ok vs.
when the CG was rebuilt, but that doesn't work because the second call
(which was supposed to rebuild the CG) returns 0 (indicating that
the CG was not rebuilt) due to the prevfailcg check causing an early
failure return. Fix this by moving the rebuild part of check_cgmagic()
out into a separate function which is called by pass1() when it wants to
rebuild a CG.
Fixes: da86e7a20d
Reported by: pho
Discussed with: mckusick
Sponsored by: Netflix
After the locking protocol changed in commit 75a67bf3d0 ("AF_UNIX:
make unix socket locking finer grained"), uipc_peeraddr() was not
updated accordingly.
The link lock now only protects global socket lists. The PCB lock is
used to protect the link between connected PCBs, so use that. Remove an
old comment which appears to be noting that unp_conn is not set for
connected SOCK_DGRAM sockets (in one direction anyway).
Reviewed by: glebius
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39855
It is not used by the in-tree default configuration, but adding it
allows downstream projects with different defaults to make use of
Cirrus-CI (as the makeman test added in 85e8c2a034 requires that
there are no missing option descriptions).
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39936
When shutdown(..., SHUT_WR) is called in the front states, send a
SHUTDOWN chunk when a COOKIE ACK chunk is received and there is
no outstanding data.
MFC after: 1 week
The fgetln loop will terminate with buf = NULL at EOF.
Reported by: GCC
Reviewed by: kp
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39947
Notable upstream pull request merges:
#11680 Add support for zpool user properties
#14145 Storage device expansion "silently" fails on degraded vdev
#14405 Create zap for root vdev
#14659 Allow MMP to bypass waiting for other threads
#14674 Miscellaneous FreBSD compilation bugfixes
#14692 Fix some signedness issues in arc_evict()
#14702 Fix typo in check_clones()
#14715 module: small fixes for FreeBSD/aarch64
#14716 Trim needless zeroes from checksum events
#14719 vdev: expose zfs_vdev_max_ms_shift as a module parameter
#14722 Fix "Detach spare vdev in case if resilvering does not happen"
#14723 freebsd clone range fixes
#14728 Fix BLAKE3 aarch64 assembly for FreeBSD and macOS
#14735 Fix in check_filesystem()
#14739 Fix data corruption when cloning embedded blocks
#14758 Fix VERIFY(!zil_replaying(zilog, tx)) panic
#14761 Revert "ZFS_IOC_COUNT_FILLED does unnecessary txg_wait_synced()"
#14774 FreeBSD .zfs fixups
#14776 FreeBSD: make zfs_vfs_held() definition consistent with declaration
#14779 powerpc64: Support ELFv2 asm on Big Endian
#14788 FreeBSD: add missing vop_fplookup assignments
#14789 PAM: support the authentication facility
#14790 Revert "Fix data race between zil_commit() and zil_suspend()"
#14795 Fix positive ABD size assertion in abd_verify()
#14798 Mark TX_COMMIT transaction with TXG_NOTHROTTLE
#14804 Correct ABD size for split block ZIOs
#14806 Use correct block pointer in block cloning case.
#14808 blake3: fix up bogus checksums in face of cpu migration
Obtained from: OpenZFS
OpenZFS commit: d96e29576c
Functions manipulating source nodes can fail due to various reasons like
memory allocation errors, hitting configured limits or lack of
redirection targets. Ensure those errors are properly caught and
propagated in the code. Increase the error counters not only when
parsing the main ruleset but the NAT ruleset too.
Cherry-picked from development of D39880
Reviewed by: kp
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D39940
Whilst we don't have ahci(4) currently, we do have umass(4), and need
pass(4) for smartctl(8) to be able to talk to such devices.
Reported by: David Gilbert <dgilbert@daveg.ca>
MFC after: 1 week
rtld's Makefile used to add -L${LIBDIR} to LDFLAGS when MK_TOOLCHAIN was
no. This was done as part of a change to fix building rtld with
MK_TOOLCHAIN == no (although I'm not sure this part was necessary).
In any case as of 5f2e84015d libc_pic.a is built independent of the
MK_TOOLCHAIN setting and the main part of the workaround has already
been removed. Remove the rest now.
This reverts commit c0f5aeb032.
Reviewed by: jrtc27
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39938
Use the new IfAPI interface and address iterators so the nfs driver
doesn't need direct access to the interface structures.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D38962
if_llmaddr_count() only counts link-level multicast addresses.
hv_netvsc(4) needs to know if there are any multicast addresses. Since
hv_netvsc(4) is the only instance where this would be used, make it a
simple boolean. If others need a if_maddr_count(), that can be added in
the future.
Reviewed by: melifaro
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D39493
We always build the kernel floating point support. Now that the
riscv64sf userspace variant has been removed the option is required for
correct operation.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39851
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Brian Atkinson <batkinson@lanl.gov>
Signed-off-by: Pawel Jakub Dawidek <pawel@dawidek.net>
Closes#14806
Clang specific pragmas need to be wrapped to prevent a build
warning when compiling with gcc.
Reviewed-by: Tino Reichardt <milky-zfs@mcmilk.de>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes#14814
In addition to the 'M' and 'O' scripts (for when 'Managed' and 'Other'
flags are set) also introduce an 'always' script that is called for any
router advertisement (so even if M and O are not set).
This is primarly useful for systems like pfSense that wish to be
informed of routers for further system configuration.
See also https://redmine.pfsense.org/issues/14072
Reviewed by: melifaro
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D39931
Early versions of the VT-d spec mentioned 6-level paging support as a
possible value for the SAGAW capability, but later versions removed it
and SAGAW=0x10 is currently listed as a reserved value.
The 6-level (agaw=64) entry in sagaw_bits is furthermore problematic
with clang15 because the attempted comparison against 1ULL << 64 in
dmar_maxaddr2mgaw() causes the compiler to elide the last iteration
of the initial loop, which bypasses the subsequent logic to find the
greatest HW-supported address width. This results in 5-level paging
always being selected regardless of whether the hardware supports it,
which can result address translation failure due to invalid context-
entry programming.
Reviewed by: kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39896
This change eliminates the struct pmap_pcid array embedded into struct
pmap and sized by MAXCPU, which would bloat with MAXCPU increase. Also
it removes false sharing of cache lines, since the array elements are
mostly locally accessed by corresponding CPUs.
Suggested by: mjg
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D39890
Cpuid is used to index the pmap->pm_pcids array only.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D39890
to initialize pm_pcids array for a new user pmap
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D39890
and rename the structure to pmap_pcid.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D39890
Prior to 590461a4b8 installation of include files was controlled
directly by ${MK_TOOLCHAIN}. 590461a4b8 added an INCLUDES knob
defaulting to YES. Setting WITHOUT_TOOLCHAIN forced it off to retain
existing behaviour.
Decouple them now, as there are reasonable use cases for installing
libraries and include files without a compiler or other tool chain
components.
Reviewed by: imp, jrtc27
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39918
This is a temporary measure until a better fix is sorted out.
Reviewed-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Rich Ercolani <rincebrain@gmail.com>
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Sponsored by: Rubicon Communications, LLC ("Netgate")
Closes#14785Closes#14808
Currently when layering the ABD buffer of each split block on top of
an indirect vdev's ZIO ABD we don't specify the split block's ABD.
This results in those ABDs being incorrectly sized by inheriting
the size of their parent ABD which is larger than what each split
block needs.
The above behavior isn't causing any bugs currently but can lead
to unexpected ABD sizes for people analyzing and/or working on
the ZIO codepath. This patch fixes this behavior by properly setting
the ABD size for split block ZIOs.
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Brian Atkinson <batkinson@lanl.gov>
Signed-off-by: Serapheim Dimitropoulos <serapheim@delphix.com>
Closes#14804
Add some more sanity checks to make sure we don't march off the end of
the table. Typically, smbios structures are well formed, or Windows
wouldn't boot. Sometimes they aren't, and this at least fails safe.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39794
This code was written on x86 where unaligned accesses were
easy. LinuxBoot running on aarch64 uses mmap of /dev/mem to read the
smbios table. Linux's mapping of this memory doesn't allow the normal
unaligned fixup, so we get a bus error instead. We can't use the more
natural le16dec and friends because they optimize into a single,
unaligned memory load. We don't see this issue on aarch64 UEFI because
memory is mapped such that unaligned accesses are fixed up.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39793
Add support for getting smbios from /sys/firmware/efi/systab, if
any. Add ptov mapping that uses mmap on /dev/mem to do the mapping with
64k pages (usually we only need 1 or two mappings).
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39792
Fix an off-by-one error that would mean we'd get stuck on the newline if
ACPI= wasn't first.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39817
Write a quick and dirty testing program to dump physical memory to help
test and debug the smbios.c code in new environments.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39791
Add one ifdef to upstrem code and get rid of compiling the horrible
checked-in aarch64 assembler for the boot loader that the loader will
never use. I'll attempt to upstream this and adjust as needed.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D39897
There's plenty of stack in kboot, so use it here rather than the
malloc/free dance.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D39416
We have plenty of stack in the EFI case, so use it instead of the
complicated malloc / free dance.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D39415
We have way more than 8k of stack for the current value of the zfs
bootonce attribute. Allocate buf on the stack rather than the
complicated malloc / free dance.
Sponsored by: Netflix
Reviewed by: tsoome, kevans, jhb
Differential Revision: https://reviews.freebsd.org/D39414