out* arguments are different on Linux and the i915 driver uses them.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D35942
In 1e73fbd8b we fixed an issue with POM_STICKYADDRESS being checked in
the wrong struct.
Add a basic test case for this fix.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
In collaboration with: dougm
Reviewed by: alc
Sponsored by: The FreeBSD Foundation (kib)
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D36001
- missing comma before name
- possible typo in section name: Sh CAVEAT instead of CAVEATS
- useless macro: Tn
- blank line in fill mode, using .sp
- no blank before trailing delimiter: Dv NULL?
MFC after: 3 days
- cannot parse date, using it verbatim: Dec 15, 1997"
- sections out of conventional order: Sh SEE ALSO
- possible typo in section name: Sh EXAMPLE instead of EXAMPLES
- AUTHORS section without An macro
MFC after: 3 days
iommu_gas_augment_entry updates a map entry element. Invoked as
RB_AUGMENT in RB tree code, it is applied from the point where the
tree is modified, all the way up to the root, and is also applied when
rotation moves a node down in the tree.
There are several opportunities to invoke it less. The automatic
augmentation with every rotation is a mistake. Delaying these
augmentations until RB_INSERT_COLOR or RB_REMOVE_COLOR are finishing
allows the augmentation code to be duplicated less, to work when there
is less register pressure, and to be skipped when conditions allow it:
In the double-rotate case of RB_INSERT_COLOR, augmentation after
the first rotation is not necessary when the element being moved
down the tree becomes a leaf. It was in the tree, and was a leaf,
before the RB_INSERT operation began, and so recomputing
augmentation for it would do nothing.
In the final (possibly only) rotation of RB_REMOVE_COLOR, both the
elements - the one moving up and the one moving down - end up in
the path from the deletion point to the tree root, so there's no
need to augment either of them immediately.
In RB_REMOVE, when the right child of the removed node replaces it
in tree, it began with a null left child. Replacement creates a
non-NULL left child, and then rotation may put a NULL node back in
that place. If that happens, start the augmenting-up-to-root with
the parent of that node, since augmentation would do nothing.
Adjust to avoid these needless augmentations.
Reviewed by: alc
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D35502
Restructure dmar_qi_task() so as to reduce the number of invalidation
completion interrupts. Specifically, because processing completed
invalidations in dmar_qi_task() can take quite some time, don't reenable
completion interrupts until processing has completed a first time. Then,
check a second time after reenabling completion interrupts, so that
any invalidations that complete just before interrupts are reenabled
do not linger until a future invalidation might raise an interrupt.
(Recent changes have made checking for completed invalidations cheap; no
locking is required.)
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36054
Since the likelihood of new Book-E PowerPC SoCs being produced is near
zero clamp MAXCPU to around the highest number of cores/threads
available currently, for both 64-bit and 32-bit. Even though the
current highest core/thread count is 24, the cap is set at 32 in case
there is code that assumes power of 2.
pass inet proto icmp icmp-type {unreach}
pass route-to (if0 127.0.0.1/8) sticky-address inet
The wrong struct was being tested. The parser tries to prevent
"sticky-address sticky-address" syntax but was actually cross-rule
enforcing that ICMP filter cannot be before the use of "sticky-address"
in next rule.
MFC after: 2 weeks
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D36050
When printing the current state name and the old state numeric value,
both are always the same. Remove the redundant ostate. It is always
the same as iv_state.
Reviewed by: bz
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35849
Security update to unbound.
PR: 265645
Security: CVE-2022-30698, CVE-2022-30699
Security: bc43a578-14ec-11ed-856e-d4c9ef517024
MFC after: 3 days
Merge commit '9b76d32f2310b735dbeb896cbf2776cad61f23e8' into main
BPF might put an interface in promiscuous mode when handling the
BIOCSDLT ioctl. When this happens, a flag is set in the BPF descriptor
so that the old interface can be restored when the BPF descriptor is
destroyed.
The BIOCPROMISC ioctl can also be used to put a BPF descriptor's
interface into promiscuous mode, but there was nothing synchronizing the
flag. Fix this by modifying the ioctl handler to acquire the global BPF
mutex, which is used to synchronize ifpromisc() calls elsewhere in BPF.
Reviewed by: kp, melifaro
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36045
Upon reset, this register is supposed to have a value of zero. But when
booting certain v7 CPUs in QEMU, we enter the kernel with several bits
set, including the EAE bit, which enables ARM's PAE extension. I'm not
sure if QEMU is setting it or if it's the uboot loader. Because FreeBSD
doesn't implement that extension and uses regular 32-bit page tables,
the kernel hangs immediately after enabling the MMU.
Just clear everything in TTBCR before enabling the MMU, to match the
reset value. FreeBSD doesn't toggle anything in that register.
PR: 251187
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36041
