Using .ALLSRC may get additional arguments that we may not want
and could cause the objcopy to fail.
Reviewed by: emaste
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D39639
PF_TABLE_STATS_ASSERT() should be checking pf_table_stats_lock not
pf_rules_lock.
Fortunately the define is not yet used anywhere so this was harmless.
Fix it anyway, in case it does get used.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Failure to get mbufs may be transient.
Don't permanently fail to open the channels due to lack of mbufs.
This also makes modifying channel parameters faster.
MFC after: 1 week
Sponsored by: NVIDIA Networking
Implement one CQ modify function supporting all firmware versions,
instead of having more variants of CQ modify.
MFC after: 1 week
Sponsored by: NVIDIA Networking
When using hardware pacing, this value can be increased, because more SQ's
means more EQ events aswell. Make it tunable, hw.mlx5.comp_eq_size .
MFC after: 1 week
Sponsored by: NVIDIA Networking
If you currently turn BB logging on and in combination have TCP Accounting on we can get a
crash where we have no NULL check and we run out of memory. Also lets make sure we
don't do a divide by 0 in calculating any BB ratios.
Reviewed by: tuexen
Sponsored by: Netflix Inc
Differential Revision:https://reviews.freebsd.org/D39622
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.
