Add CPUTYPE and MACHINE_CPUARCH to the list of variables printed
when there are build errors.
Protect local.sys.mk from multiple inclusion.
Reviewed by: sjg
Obtained from: Juniper Networks, Inc.
Summary:
Include details from the SMBIOS 3 specification and some additional
details for SMBIOS 2.1.
Obtained from: Juniper Networks, Inc.
Reviewers: jmg, manu
Subscribers: imp, dab
Differential Revision: https://reviews.freebsd.org/D39635
The VV_CROSSLOCK handling logic may need to upgrade the covered
vnode lock depending upon the requirements of the filesystem into
which vfs_lookup() is walking. This may involve transiently
dropping the lock, which can allow the target mount to be unmounted.
Tested by: pho
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D39272
The underlying VOP_MKDIR() implementation may temporarily drop the
parent directory vnode's lock. If the vnode is reclaimed during that
window, the unionfs vnode will effectively become unlocked because
the its v_vnlock field will be reset. To uphold the locking
requirements of VOP_MKDIR() and to avoid triggering various VFS
assertions, explicitly re-lock the unionfs vnode before returning
in this case.
Note that there are almost certainly other cases in which we'll
similarly need to handle vnode relocking by the underlying FS; this
is the only one that's caused problems in stress testing so far.
A more general solution, such as that employed for nullfs in
null_bypass(), will likely need to be implemented.
Tested by: pho
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D39272
The implementation is racy; if the unionfs vnode is not in fact
locked, vnode private data may be concurrently altered or freed.
Instead, simply rely upon the standard implementation to query the
v_vnlock field, which is type-stable and will reflect the correct
lower/upper vnode configuration for the unionfs node.
Tested by: pho
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D39272
We hold the vnode interlock, so vnode private data cannot suddenly
become NULL.
Tested by: pho
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D39272
The LK_UPGRADE operation may have temporarily dropped the upper or
lower vnode's lock. If the unionfs vnode was reclaimed during that
window, its lock field will be reset to no longer point at the
upper/lower vnode lock, so the lock operation will use the standard
lock stored in v_lock. Remove LK_UPGRADE from the flags in this case
to avoid a lockmgr assertion, as this lock has not been previously
owned by the calling thread.
Reported by: pho
Tested by: pho
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D39272
4aeb63826e got it almost correct (we can't use strcmp() here as
current argument isn't guaranteed to be NUL-terminated), but we also
need to check that current argument length is equal to that of eofstr.
PR: 270867
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D39583
A one-bit wide bit-field can take only the values 0 and -1. Clang 16
introduced a warning that "implicit truncation from 'int' to a one-bit
wide bit-field changes value from 1 to -1". Fix by using c99 bool.
Reported by: Clang, via dim
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
The recent 25685b7537 came in conflict with a540cdca31. Remove the
code that cleans up the old style input queue. Note that two lines
below we assert that the new style input queue is empty. The TCP
stacks that use the queue are supposed to flush it in their
tfb_tcp_fb_fini method.
lld >= 16 became more strict about multiply defined symbols. Since there
are many of those in crunchgen'd programs, turn off the check when
linking the rescue binary.
MFC after: 1 week
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by various declarations in libarchive:
contrib/libarchive/libarchive/archive_write_set_format_7zip.c:1541:13: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
file->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5127:15: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5213:14: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5214:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->virtual = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7149:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->virtual = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7435:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.detect_magic = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7495:25: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.making = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7496:26: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.allzero = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7702:28: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.allzero = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7871:25: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
zisofs->header_passed = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7894:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
zisofs->initialized = 1;
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the fields as booleans, so make them unsigned.
This has also been sent upstream.
MFC after: 3 days
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by a declaration in libsa's tftp.c:
stand/libsa/tftp.c:382:20: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
h->islastblock = 1; /* very short file */
^ ~
stand/libsa/tftp.c:432:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
h->islastblock = 1; /* EOF */
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the field as a boolean, so make it unsigned.
MFC after: 3 days
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by a declaration in bsnmp's snmpd.h:
contrib/bsnmp/snmpd/trans_lsock.c:271:21: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
peer->input.stream = 1;
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the field as a boolean, so make it unsigned.
MFC after: 3 days
lld >= 16 turned on --no-undefined-version by default, which results in
errors whenever symbols are mentioned in version maps, but are not
actually defined in the binary.
Since we have quite a few instances of symbols that are defined or not,
depending on various compile-time settings, suppress this lld check for
the time being.
MFC after: 1 week
Expect that drivers call into the network stack with the net epoch
entered. This has already been the fact since early 2020. The net
interrupts, that are marked with INTR_TYPE_NET, were entering epoch
since 511d1afb6b. For the taskqueues there is NET_TASK_INIT() and
all drivers that were known back in 2020 we marked with it in
6c3e93cb5a. However in e87c494015 we took conservative approach
and preferred to opt-in rather than opt-out for the epoch.
This change not only reverts e87c494015 but adds a safety belt to
avoid panicing with INVARIANTS if there is a missed driver. With
INVARIANTS we will run in_epoch() check, print a warning and enter
the net epoch. A driver that prints can be quickly fixed with the
IFF_NEEDSEPOCH flag, but better be augmented to properly enter the
epoch itself.
Note on TCP LRO: it is a backdoor to enter the TCP stack bypassing
some layers of net stack, ignoring either old IFF_KNOWSEPOCH or the
new IFF_NEEDSEPOCH. But the tcp_lro_flush_all() asserts the presence
of network epoch. Indeed, all NIC drivers that support LRO already
provide the epoch, either with help of INTR_TYPE_NET or just running
NET_EPOCH_ENTER() in their code.
Reviewed by: zlei, gallatin, erj
Differential Revision: https://reviews.freebsd.org/D39510
veriexec_check_path_label() can be used to check if a specified
path has a label associated with it that contains the what we
want.
Obtained from: Juniper Networks, Inc.
Some 32bit apps may need to be able to use
MAC_VERIEXEC_GET_PARAMS_PID_SYSCALL
MAC_VERIEXEC_GET_PARAMS_PATH_SYSCALL
Therefore compat32 support is required.
Obtained from: Juniper Networks, Inc.
Ensure veriexec opens the file before doing any read operations.
When the MAC_VERIEXEC_CHECK_PATH_SYSCALL syscall is requested, veriexec
needs to open the file before calling mac_veriexec_check_vp. This is to
ensure any set up is done by the file system. Most file systems do not
explicitly need an open, but some (e.g. virtfs) require initialization
of access tokens (file identifiers, etc.) before doing any read or write
operations.
The evaluate_fingerprint() function needs to ensure it has an open file
for reading in order to evaluate the fingerprint. The ideal solution is
to have a hook after the VOP_OPEN call in vn_open. For now, we open the
file for reading, envaluate the fingerprint, and close the file. While
this leaves a potential hole that could possibly be taken advantage of
by a dedicated aversary, this code path is not typically visited often
in our use cases, as we primarily encounter verified mounts and not
individual files. This should be considered a temporary workaround until
discussions about the post-open hook have concluded and the hook becomes
available.
Add MAC_VERIEXEC_GET_PARAMS_PATH_SYSCALL and
MAC_VERIEXEC_GET_PARAMS_PID_SYSCALL to mac_veriexec_syscall so we can
fetch and check label contents in an unconstrained manner.
Add a check for PRIV_VERIEXEC_CONTROL to do ioctl on /dev/veriexec
Make it clear that trusted process cannot be debugged. Attempts to debug
a trusted process already fail, but the failure path is very obscure.
Add an explicit check for VERIEXEC_TRUSTED in
mac_veriexec_proc_check_debug.
We need mac_veriexec_priv_check to not block PRIV_KMEM_WRITE if
mac_priv_gant() says it is ok.
Reviewed by: sjg
Obtained from: Juniper Networks, Inc.
The contents of frame->tf_tp are uninitialized if accessed by DTrace (in
probe context), resulting in a panic when trying to access the memory
pointed to by tp. This saves the thread pointer to the trap frame when
handling both userland and kernel exceptions.
Reviewed by: markj, mhorne
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39582
For diff reduction against NetBSD's makefs. Based on NetBSD git mirror
commit 00991aee8248.
With this change our makefs cd9660 support should be in sync up to
NetBSD commit bdae6c9dc792 ("makefs(8): Nix trailing whitespace.").
Sponsored by: The FreeBSD Foundation
Keep block cloning disabled by default for now, but allow to enable and
use it after setting vfs.zfs.bclone_enabled to 1, so people can easily
try it.
Approved by: oshogbo
Reviewed by: mm, oshogbo
Differential Revision: https://reviews.freebsd.org/D39613
939a050ad9 virtualized lagg(4), but the corresponding sysctl of some
virtualized global variables are not marked with CTLFLAG_VNET. A try to
operate on those variables via sysctl will effectively go to the 'master'
copies and the virtualized ones are not read or set accordingly. As a
side effect, on updating the 'master' copy, the virtualized global
variables of newly created vnets will have correct values.
PR: 270705
Reviewed by: kp
Fixes: 939a050ad9 Virtualize lagg(4) cloner
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39467
The zfs_log_clone_range() function is never called from the
zfs_clone_range_replay() function, so I assumed it is safe to assert
that zil_replaying() is never TRUE here. It turns out zil_replaying()
also returns TRUE when the sync property is set to disabled.
Fix the problem by just returning if zil_replaying() returns TRUE.
Reported by: Florian Smeets
Signed-off-by: Pawel Jakub Dawidek pawel@dawidek.net
Approved by: oshogbo, mm
Fix data corruption when cloning embedded blocks
Don't overwrite blk_phys_birth, as for embedded blocks it is part of
the payload.
Reviewed-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Pawel Jakub Dawidek <pawel@dawidek.net>
Issue #13392Closes#14739
Approved by: oshogbo, mm
meta2deps - add checks to detect truncated/corrupted filemon data
(only known to happen on Linux hosts), to ensure we do not auto
update dependencies based on incomplete data.
meta.stage.mk adds STAGE_SHLIB_LINKS_FILTER and STAGE_LINK_AS_*
We also allow for hosts where egrep is deprecated for grep -E
Reviewed by: stevek
