NAS-141973 / 26.0.0-RC.1 / fix invalid maximum advertisement VRRP timeout value (#19406)
A fun one. Exposed by a real customer escalation. They had put 3600 as a
value into our API. We accepted it with no validation. The underlying
daemon we use (keepalived) does not allow values this high, especially
since we use VRRPv3. The gist is simple, the exceedingly high value that
we didn't validate was written to the keepalived.conf file and the
service failed to start without any real indication to the support team
or customer ultimately preventing failover from occurring.
Let's go ahead and fix this situation by adding a migration to clamp any
values > 120 seconds to 120 seconds. Do note that the advertisement
timeout is in centiseconds per the RFC but we expose the value to the
customer as seconds.
Fix filesystem.put ACL handling and use zc mechanisms
This commit ensures that we strip any existing filesystem ACL
on a file we're writing to truenas via filesystem.put prior to
setting the mode specified in the API call (to ensure it doesn't
fail if aclmode is set to RESTRICTED). Additionally, this
commit transitions us to using sendfile / splice for copying
to / from pipes for these jobs.
net/bgpipe: Add bgpipe-0.22.0
Open-source tool that processes BGP messages through
a pipeline of composable stages.
What is bgpipe?
bgpipe sits between routers as a transparent proxy, auditing,
filtering, and transforming BGP sessions on the fly.
Think of it as a scriptable BGP firewall and traffic processor.
Use cases:
* BGP firewall with RPKI validation, prefix limits, and rate limiting
* Bidirectional BGP to JSON translation including Flowspec - pipe through
jq, Python, anything
* MRT file processing and conversion at scale, incl. RIB snapshots (table dumps)
* Scriptable pipeline - chain stages or pipe through external programs
* Live BGP monitoring from RIPE RIS Live or RouteViews with real-time filters
* Secure transport - add TCP-MD5 to sessions, proxy over encrypted WebSockets
[28 lines not shown]
[Clang] [NFC] Update OptionalUnsigned ctor to only reject signed integers (#212321)
Currently, the `OptionalUnsigned(int) = delete;` constructor means that
constructing e.g. an `OptionalOrUnsigned<uint64_t>` from an `unsigned`
fails because overload resolution is ambiguous (because `unsigned` ->
`int` and `unsigned` -> `uint64_t` are both valid conversions). This
patch adds a constraint to make sure the deleted constructor only
catches signed integer types.
This is needed for #212319.
[OFFLOAD][L0] Fix zero argurment kernel launch (#212296)
PR #205224 changed the path for kernels with no arguments to not use
appendLaunchKernelWithArgs, while at the same time it removed
zeKernelSetGroupSize which resulted in incorrect sizing of the kernel.
This PR removes the alternate path and makes sure all launches go
through appendLaunchKernelWithArgs.
Alternatively we can restore zeKernelSetGroupSize on the alternate path.
[AMDGPU] Allow scalar operands in V_PK_LSHL_ADD_U64
Patch creates dummy source modifiers for this instruction to use
with OPSEL. Even though these do not support modifiers we can reuse
the same mechanics as with packed fp64 and other u64 to allow scalar
operands.
[BOLT] Fix strict mode bug in removal of block referenced by JT (#211940)
Summary:
BOLT can create a jump table object from a PC-relative operand reference
(e.g. leaq JT(%rip)) whenever the referenced memory looks like a PIC
jump table -- see
BinaryContext::handleAddressRef. This is independent of whether BOLT
recognizes the indirect jump dispatch itself. The jump table annotation
is only attached to the jmp instruction later, in
BinaryFunction::analyzeIndirectBranch, and only when the target-specific
analyzeIndirectBranch matcher recognizes the dispatch pattern.
If the matcher does not recognize the pattern, the annotation is never
attached to the jmp, even though the jump table object and its entries
exist and reference basic blocks in the function.
In strict mode BOLT still fully processes such a function: it stays
simple, the block is marked as having unknown control flow, and the jump
table object is kept intact. Because the terminator carries no jump
[11 lines not shown]
[BOLT] Release pseudo-probe decoder after emit (#211935)
PseudoProbeRewriter builds sizable data structures and then hold onto
them after they are needed.
PseudoProbeRewriter::postEmitFinalizer() parses the input .pseudo_probe
sections into an MCPseudoProbeDecoder whose address-to-probe and
GUID-to-function-desc maps can be very large (tens of GiB on big
binaries with many probes). This is not used again once probes have been
updated, yet they survive into the memory-heavy DWARF rewrite
(updateDebugInfo), directly inflating BOLT's peak RSS at the worst
possible time.
This frees them at the end of the postEmitFinalizer() calls, before
updateDebugInfo runs.
Stacked on top of the .dwo DIE diff, in large binaries you should
observe ~17% peak RSS wins if your
build uses pseudo probe maps.
inpcb: declare struct in_conninfo as a single declaration
This removes just one level of #define mess that is needed to reach into
an inpcbs IPv4 address. And makes the declaration easier to read. No
functional change.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58273
