The recent commit to fix a gzip header extra field processing bug
introduced the new bug fixed here.
(cherry picked from zlib commit 1eb7682f845ac9e9bf9ae35bbfb3bad5dacbd91d)
They do not have the same pmap api and this cannot work for those arch.
Fixes: 789dbdbb48 ("linuxkpi: Add arch_io_{reserve,free}_memtype_wc")
Sponsored by: Beckhoff Automation GmbH & Co. KG
Fix two bugs in __cxa_end_cleanup()
Per the EHABI32 specification, __cxa_end_cleanup must take care to
preserve registers before calling _Unwind_Resume(). So, libcxxrt uses
an assembly stub which preserves caller-saved registers around the call
to __cxa_get_cleanup(). But:
- it failed to restore them properly,
- it did not preserve the link register.
Fix both of these problems. This is needed to fix exception unwinding
on FreeBSD with LLVM 14. Note that r4 is callee-saved but is pushed
onto the stack to preserve stack pointer alignment.
Sponsored-by: The FreeBSD Foundation
MFC after: 1 week
Structure l9p_f_wralk reserves at most L9P_MAX_WELEM entries
and that number actually set the maximum we can safely use.
PR: 265385
Reviewed by: markj
MFC after: 1 day
Differential Revision: https://reviews.freebsd.org/D35907
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