Use of stdatomic.h is undefined in C++, even the C++ 2020 standard does not
list stdatomic.h as a C library header supported by the language. More,
there are some subtle differences between the <atomic> C++ header, and
C11+ stdatomic.h provided features.
Nonetheless, it is a quality of the implementation aspect, so let mis-users
mis-use stdatomic.h as they want, by making a compat shim for _Bool.
PR: 262683
Reported by: yuri
Reviewed by: dim, emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D34686
In contrast to Linux it does not provide entries which can be readlinked
-- these are just regular files, not giving the expected outcome. That's
on top of procfs not being mounted by default to begin with.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D34684
This completes the patch which was originally meant to go in.
Spotted by: mhorne
Fixes: c35ec1efdc ("vfs: [1/2] fix stalls in vnode reclaim by not
requeieing from vnlru")
Bugfixes:
IS #1672 and OSS-Fuzz #38766:
(zip reader) fix possible out-of-bounds read in zipx_lzma_alone_init()
PR #1676: (mtree reader) remove the unused variable "detected_bytes"
PR #1674: (doc) fix use of At mdoc(7) macro in cpio.5
MFC after: 3 days
Bugfixes:
IS #1672 and OSS-Fuzz #38766:
(zip reader) fix possible out-of-bounds read in zipx_lzma_alone_init()
PR #1676: (mtree reader) remove the unused variable "detected_bytes"
PR #1674: (doc) fix use of At mdoc(7) macro in cpio.5
Obtained from: libarchive
Libarchive commit: cfaa28168a07ea4a53276b63068f94fce37d6aff
Turns out clang converts "memcmp(foo, bar, len) == 0" and similar to
bcmp calls.
Reviewed by: emaste (previous version), jhb (previous version)
Differential Revision: https://reviews.freebsd.org/D34673
Avoid a null dereference when a value-less jailsys parameter is passed
to "jail -m". There was already code to handle boolean parameters,
but in reality any parameter could be passed without a value.
It was only called in the non-NUMA and single-domain paths.
Some of its assertions were duplicated in uma_zalloc_domain,
but some things were missed, especially memguard.
Reviewed by: markj, rstone
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34472
The man page said dynamic allocation was required, but struct stack
can be allocated in any way, including on the stack. Make this clear,
and explain how to initialize the struct.
While I'm here, stack_save does not require any lock.
Reviewed by: markj, Pau Amma <pauamma_gundo.com>
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34461
The uma_zalloc functions expect exactly one of [M_NOWAIT, M_WAITOK].
If neither or both are passed, print an error and a stack dump.
Only do this ten times, to prevent livelock. In the future, after
this exposes enough bad callers, this will be changed to a KASSERT().
Reviewed by: rstone, markj
MFC after: 1 month
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34452
It expects exactly one of those flags. A future commit will assert this.
Reviewed by: rstone
MFC after: 1 month
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34451
uma_zalloc_arg expects exactly one of the two WAIT flags. A future
commit will assert this.
Reviewed by: rstone
MFC after: 1 month
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34450
Turns out execve looks at it to store binary name, but in order to
trigger the problem one has to be trying to exec '/'. As is the value
would be left uninitialized (or rather set to -1 on debug kernels).
Fixes: 56244d3574 ("vfs: hoist degenerate path lookups out of the
loop")
This can leak kernel stack data otherwise.
Reviewed by: imp, markj
Sponsored by: The University of Cambridge, Google, Inc.
Differential Revision: https://reviews.freebsd.org/D34594
Following ARMARM sec D5.2.11, which says:
> Where an instruction results in an update to a System register,
> as is the case with the AT * address translation instructions,
> explicit synchronization must be performed before the result is
> guaranteed to be visible to subsequent direct reads of the
> PAR_EL1.
Reviewed By: andrew
MFC after: 3 weeks
Sponsored by: Ampere Computing
Differential Revision: https://reviews.freebsd.org/D34665
Bits 43:0 of the TLBI operand are bits 55:12 of the VA. Leaving
bits 63:55 of the VA in bits 51:44 of the operand might wind up
setting the TTL field (47:44) and accidentally restricting which
translation levels are flushed in the TLB.
Reviewed By: andrew
MFC after: 3 days
Sponsored by: Ampere Computing
Differential Revision: https://reviews.freebsd.org/D34664
Specific to Linux AT_NO_AUTOMOUNT flag tells the kernel to not automount the
terminal component of pathname if it is a directory that is an automount point.
As it is the default for FreeBSD silencly ignore this flag.
glibc-2.34 uses this flag in the stat64 system calls which is used by i386.
Reviewed by: trasz
Differential revision: https://reviews.freebsd.org/D31524
MFC after: 2 weeks
Disallow the use of tables in ethernet rules. Using tables requires
taking the PF_RULES lock. Moreover, the current table code isn't ready
to deal with ethernet rules.
Disallow their use for now.
Sponsored by: Rubicon Communications, LLC ("Netgate")
The firmware doesn't report FORCE_FEC in pcaps if the transceiver
plugged in at that time does not support a speed that may use FEC. It
is incorrect for the driver to assume that the FORCE_FEC value it read
during attach (in init_link_config) is permanent. Instead, it should
check pcaps just before issuing the L1CFG command.
MFC after: 1 week
Sponsored by: Chelsio Communications
Cleanup some debugging. Rename the global variable to be less
generic. Hide all debugging behind #ifdef for now and turn off.
Rename the debugging sysctl so we can start adding more to the
subtree.
There is a need to change that wildly grown infrastructure into
something more homogenic soon but this should do for 13.1.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
This register set contains the values of the fsbase and gsbase
registers. Note that these registers can already be controlled
individually via ptrace(2) via MD operations, so the main reason for
adding this is to include these register values in core dumps. In
particular, this will enable looking up the value of TLS variables
from core dumps in gdb.
The value of NT_X86_SEGBASES was chosen to match the value of
NT_386_TLS on Linux. The notes serve similar purposes, but FreeBSD
will never dump a note equivalent to NT_386_TLS (which dumps a single
segment descriptor rather than a pair of addresses) and picking a
currently-unused value in the NT_X86_* range could result in a future
conflict.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D34650
Extending what was started in d3ef7fb459,
when a driver signals that hw_scan is not possible and expects a sw_scan
to be preformed we triggered a sw_scan towards the driver but did not
let net80211 know.
Cancel the initial scan towards net80211. If we we defer to sw_scan
then clear IEEE80211_FEXT_SCAN_OFFLOAD so net80211 will send probe
requests, and actively start a new scan with net80211.
This may have to be further refined in the future but seems to work
for the moment.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Remove the originally disabling of (*ic_scan_curchan), which for iwlwifi
was not needed. The condition always only was approximate.
A set IEEE80211_FEXT_SCAN_OFFLOAD will still prevent net80211 from sending
probe_reqs if handled by driver/firmware.
ic_scan_curchan will re-arm the timer to switch channels for drivers which
need it (e.g., rtw88, but that again is a NOP for iwlwifi).
So enabling ic_scan_curchan should not have further side effects for iwlwifi
but allow other drivers to work better.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
When checking for IEEE80211_FEXT_SCAN_OFFLOAD, do so on the vap rather
than ic. This brings us in line with what net80211 does.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
For (*config)() based drivers not using chanctx we need to use
ic_set_channel() to switch channels. So far this was disabled
based on scanning flags (as swscan is one of the initial use cases
for this function). Now make it only dependent on (*config)()
for the moment to save us the work if (*config)() is not supported.
For iwlwifi (*config)() is a NOP so no functional changes there
but for other drivers such as rtw88 this will allow us to scan and
set the channel (which helps to receive on channels other than 1).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
The keyboard driver was initially protected via spl* interrupt priority
calls but (as part of a comprehensive effort) migrated to use the Giant
lock (mutex).
The spl calls left behind became NOPs but they can be confusing as they
have no bearing on the actual mutual exclusion that is now present.
Remove them from kbd and add assertions that Giant is held. markj notes
that there is conflation between the "bus topo" lock (which is Giant
under the hood) and Giant. The assertions could either be addressed as
a small item along with bus topology locking work or they'll be removed
if kbd is decoupled from Giant.
PR: 206680
Reviewed by: markj
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34645
Rather than manually setting up a chandef and then effectively forcing
a memcpy, use cfg80211_chandef_create() to do the work for us entirely.
This works here as we do not store the resulting chandef separately
for other use.
While here remove a duplicate assignment in cfg80211_chandef_create().
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
If a driver does not support (*sta_state)() we internally in
lkpi_80211_mo_sta_state() fall back to using (*sta_add/*sta_remove)().
In that case add tracking of both added_to_drv and state fields for the
lsta so that our state machine keeps working and assertions do not fire.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
This permits I/O devices on the host to directly access wired memory
dedicated to guests using passthru devices. Note that wired memory
belonging to guests that do not use passthru devices has always been
accessible by I/O devices on the host.
bhyve maps guest physical addresses into the user address space of
the bhyve process by mmap'ing /dev/vmm/<vmname>. Device models pass
pointers derived from this mapping directly to system calls such as
preadv() to minimize copies when emulating DMA. If the backing store
for a device model is a raw host device (e.g. when exporting a raw disk
device such as /dev/ada<n> as a drive in the guest), the host device
driver (e.g. ahci for /dev/ada<n>) can itself use DMA on the host
directly to the guest's memory. However, if the guest's memory is
not present in the host IOMMU domain, these DMA requests by the host
device will fail without raising an error visible to the host device
driver or to the guest resulting in non-working I/O in the guest.
It is unclear why guest addresses were removed from the IOMMU host domain
initially, especially only for VM's with a passthru device as the
host IOMMU domain does not affect the permissions of passthru devices,
only devices on the host.
A considered alternative was using bounce buffers instead (D34535
is a proof of concept), but that adds additional overhead for unclear
benefit.
This solves a long-standing problem when using passthru devices and
physical disks in the same VM.
Thanks to: grehan (patience and help)
Thanks to: jhb (for improving the commit message)
PR: 260178
Reviewed by: grehan, jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D34607
