ena: Verify that an ENA ring is in netmap only in native mode
netmap operates in two modes:
1) Emulated - netmap handling is done by the network stack, the
NIC driver operates transparently to netmap.
2) Native - netmap management is done by the NIC driver.
When checking whether a specific ENA ring is running in netmap
mode, only the following checks were done:
1. IFCAP_NETMAP - Check whether netmap capability is enabled on
the device.
2. NKR_NETMAP_ON - Check whether netmap is actively using this
ring.
The above checks implied that the netmap mode is native and the
ENA driver needs to handle the netmap logic.
The code was missing an explicit check on whether native mode
is actually on (NAF_NATIVE).
This led to a case where though emulated mode was used and
[19 lines not shown]
ena: Minor changes
1. Move parenthesis to correct place in switch and fix include order
2. Add comment at the end of an ifdef for clarity
3. Change include order.
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D55696
Sponsored by: Amazon, Inc.
(cherry picked from commit 2667a8454cff5896c7b467c78cd4ace5ad40f5eb)
ena: Update driver version to v2.8.2
Bug Fixes:
* Verify that an ENA ring is in netmap only in native mode
Minor Changes:
* Move parenthesis to correct place in switch
* Add comment
* Reorder define
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D55698
Sponsored by: Amazon, Inc.
(cherry picked from commit 96c5eaf0ac6b98d0832e1037d672064de43a7e00)
security/zaproxy: Update JAVA_VERSION to 17+
- JAVA 22 will be removed soon so 17+ shows us the current java versions
supported by zaproxy
- Bump PORTREVISION
PR: 294176
Reported by: ronald
[lldb] Simplify some tests to run_to_source_breakpoint (NFC) (#190082)
Many tests have ad hoc forms of the launch & break steps done by
`lldbutil.run_to_source_breakpoint`. This changes some of those tests to
use `run_to_source_breakpoint` instead.
Assisted-by: claude
Use setExprNeedsCleanups in BuildCXXNew and avoid breaking c++98
This approach is much cleaner, but broke checkICE reporting in c++98.
Stepping through a debugger shows that this happend because the
static_assert test didn not recognize ExprWithCleanups as transparent to
constant evaluation. To addresse this, we update CheckICE to recurse
into the sub-expression, and keep the old behavior.
[clang] Use uniform lifetime bounds under exceptions
To do this we have to slightly modify how some expressions are handled
in Sema. Principally, we need to ensure that calls to new for
non-trivial types still have their destructors run. Generally this isn't
an issue, since these just get sunk into the surrounding scope. With
more lifetime annotations being produced for the expressions, we found
that some calls to `new` in an unreachable switch arm would not be
wrapped in ExprWithCleanups. As a result, they remain on the EhStack
when processing the default label, and since the dead arm doesn't
dominate the default label, we can end up with a case where the def-use
chain is broken (e.g. the def doesn't dominate all uses). Technically
this path would be impossible to reach due to the active bit, but it
still failed to satisfy a dominance relationship.
With that in place, we can remove the constraint on only using tighter
lifetimes when exceptions are disabled.
[clang] Use tighter lifetime bounds for C temporary arguments
In C, consecutive statements in the same scope are under
CompoundStmt/CallExpr, while in C++ they typically fall under
CompoundStmt/ExprWithCleanup. This leads to different behavior with
respect to where pushFullExprCleanUp inserts the lifetime end markers
(e.g., at the end of scope).
For these cases, we can track and insert the lifetime end markers right
after the call completes. Allowing the stack space to be reused
immediately. This partially addresses #109204 and #43598 for improving
stack usage.
Reapply "[clang] Limit lifetimes of temporaries to the full expression (#170517)"
This reverts commit 6d38c876478dac4a42f9d6e37692348deabf6a25. The
current version only works when exceptions are not enabled until we
determine how to resolve issues around broken dominance relationships
with the def-use chain.
ena: Minor changes
1. Move parenthesis to correct place in switch and fix include order
2. Add comment at the end of an ifdef for clarity
3. Change include order.
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D55696
Sponsored by: Amazon, Inc.
(cherry picked from commit 2667a8454cff5896c7b467c78cd4ace5ad40f5eb)
ena: Update driver version to v2.8.2
Bug Fixes:
* Verify that an ENA ring is in netmap only in native mode
Minor Changes:
* Move parenthesis to correct place in switch
* Add comment
* Reorder define
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D55698
Sponsored by: Amazon, Inc.
(cherry picked from commit 96c5eaf0ac6b98d0832e1037d672064de43a7e00)
ena: Verify that an ENA ring is in netmap only in native mode
netmap operates in two modes:
1) Emulated - netmap handling is done by the network stack, the
NIC driver operates transparently to netmap.
2) Native - netmap management is done by the NIC driver.
When checking whether a specific ENA ring is running in netmap
mode, only the following checks were done:
1. IFCAP_NETMAP - Check whether netmap capability is enabled on
the device.
2. NKR_NETMAP_ON - Check whether netmap is actively using this
ring.
The above checks implied that the netmap mode is native and the
ENA driver needs to handle the netmap logic.
The code was missing an explicit check on whether native mode
is actually on (NAF_NATIVE).
This led to a case where though emulated mode was used and
[19 lines not shown]
Special handling for exponents of 0 on m68k.
Handle moving between subnormal and normal numbers, set the hidden bit
appropriately.
This was found by libm/t_next failures on m68ksf, although failures did not
occur in an fpu emulation via qemu/mac68k.
[CIR] Fix handling of catch-all with cleanups (#190233)
We had a bug where exceptions caught with catch-all were not properly
handling a thrown exception if the catch-all handler enclosed a cleanup
handler. The structured CIR was generated correctly, but when we
flattened the CFG and introduced cir.eh.initiate operations, the
cir.eh.initiate for the cleanup's EH path was incorrectly marked as
cleanup-only, even though it chained to the dispatch for the catch-all
handler. This resulted in the landing pad generated for the cleanup not
being marked as having a catch-all handler, so the exception was not
caught.
This change fixes the problem in the FlattenCFG pass.
Assisted-by: Cursor / claude-4.6-opus-high
mtree: stop creating /usr/share/doc/ncurses
In base 68ad2b0d7af2a the ncurses html documentation was removed, and
entries added to ObsoleteFiles.inc to get rid of /usr/share/doc/ncurses,
but the directory was still being re-created via BSD.usr.dist. Remove it
from there too.
Fixes: 68ad2b0d7af2a
MFC after: 1 month
(cherry picked from commit 212272a43767c3d7be3ddb87605612f6164774c1)
