By calling the function too early we might still have the td_pflags
value cached from the previous struct thread use. cpu_copy_thread()
depends on correct value for TDP_KTHREAD at least on x86.
Reported, bisected, and tested by: pho
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D36069
When the interface does not exist avoid passing host with special pf
modifiers to DNS resolution as they come up empty anyway.
Reviewed by: kp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35429
Linux does the same.
Reviewed by: bz, emaste, hselasky
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36023
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
