This turns the uint64 metric constructor arguments into a struct, making it
more explicit as to what each part means. It also allows the creation of
non-cumulative uint64 (gauge) metrics, and adds methods to decrement or set
them.
PiperOrigin-RevId: 647134245
Also add "num" at the end of it so make it clear that it's an *inclusive*
limit. Fix the uses of it which didn't treat it as inclusive.
No strong opinion on where it should go, but having it available in
other places of the codebase is helpful. It's already in two places,
and I'd like to have it available in two more places:
- In the seccomp program compiler, so that it knows how many syscalls
it should check for deterministic-ness and caching the results.
- In the seccomp fuzzer, to build an initial syscall corpus.
PiperOrigin-RevId: 576660986
It is an idea of running codespell as part of our presubmit checks.
Before enabling it for new changes, let's fix what it has found.
Signed-off-by: Andrei Vagin <avagin@gmail.com>
This moves the initialization of `seccheck.Points` out of package-level
`init` and instead moves it to an explicit `seccheck.Initialize()` function.
On AMD64, this saves about 614KiB of heap memory that would otherwise always
be live.
PiperOrigin-RevId: 514813332
This allows a configuration file with newer trace points and fields
to be used with an older runsc without failing (just skips the new
trace points and fields).
Updates #4805
PiperOrigin-RevId: 487091892
Prior to this CL, each of the 4 syscall points (raw enter,
enter, raw exit, exit) each resulted in 1 atomic read, on top of the existing
atomic read to read non-seccheck-related per-syscall flags.
This CL propagates seccheck's syscall-related points to the existing
per-syscall flags bitfield, such that this data can be loaded in a single
atomic read per syscall, rather than 5.
This shaves off a few precious nanoseconds (-3%) from the hot syscall path.
PiperOrigin-RevId: 463190096