This is useful to be able to refer to them from external packages, such as
to represent the `ioctl(2)` syscall profile that the Sentry has with the
KVM platform.
PiperOrigin-RevId: 566705114
The --nvproxy flag allows container GPU usage to be specified via device nodes
and mounts provided in the runtime spec, as when using Kubernetes with GKE's
Nvidia GPU device plugin
(https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu).
The --nvproxy-docker flag additionally allows container GPU usage to be
specified via the NVIDIA_VISIBLE_DEVICES container environment variable, as
when using `docker --gpus`. This does not require the Nvidia Container Toolkit
(or the Nvidia Container Runtime [Hook], which are part of the Toolkit), but
does require libnvidia-container, which is typically installed as a dependency
of the Nvidia Container Toolkit.
Updates #14
PiperOrigin-RevId: 535002602
b/283566121 suggests that the `log.Warningf` formatting is introspecting some
field that it shouldn't. This adds an explicit `String` function to
`sharedContext` to avoid this issue.
PiperOrigin-RevId: 534218205
It was used to disable the fast path in stub threads. The current
implemenation has a race when subprocessList.PushBack(s) can
be called before subprocessList.Remove(s). This issue can be fixed
by introducing a new mutex to guard contextQueue.numAwakeContexts,
but it will introduce additional overhead.
It was an addition way to disable the stub fast path. We do the
same thing when a new context is added to a subprocess context queue.
PiperOrigin-RevId: 533297618
Now all threads are waiting on queue->num_thread_to_wakeup,
it is a single point for all threads.
This change allows us to avoid cases when num_active_threads
are inconsistent with threads states, because they can't be
changed atomically.
PiperOrigin-RevId: 531020012
queue_get_context reads `start`, then it gets a value of ringbuffer[start] and
increments `start` if the value is a valid context ID. The issue is that
the ring buffer can be recycled between first two operations.
This change puts an index into a buffer value. It allows us to detect when a
buffer is recycled and we read a value of a wrong index.
PiperOrigin-RevId: 529552389
Here are two conditions when the fast path is effective:
* the side that has to change a state is running on CPU when another side
is polling the state. This is why the Sentry threads have a higher
priority than stub threads.
* The sentry handles events faster than the overhead of scheduling another
stub thread.
This patch addresses the second condition. The fast path in stub threads is
disabled when we reach the limit of stub threads. The idea is that more stub
threads can generate more events to the sentry.
PiperOrigin-RevId: 529120681
A context is awake if its guest thread isn't in the interruption sleep state.
The idea here is that a task in the sleep state will not return within the fast
path timeout and so we don't need to hold a stub thread for it.
PiperOrigin-RevId: 529006216
Before this change, each task is polling its contexts. It reduces the number
of context switches but it creates extra CPU load.
This idea has been borrowed from Jamie's cl/488537531.
PiperOrigin-RevId: 528984717
We suppose that gvisor containers are running in a separate CPU cgroups,
so task priorities affect only tasks in one group.
Effectively, we increase priority of the sentry and gofers, because they
are doing functions of the kernel, so should have full controls over guest
processes. If the sentry runs with a higher priority, it can handle stub
thread events faster so it should reduce chances of triggering slow paths.
PiperOrigin-RevId: 528939329
This introduces a `metric.FieldValue` struct type that wraps a string.
All metric interfaces that deal with field values have been updated to use
pointers to this type instead of strings.
The intent of this change is to make it more obvious that field values must
be passed using references. Prior to this change, this was done using string
pointer comparisons. Now this must be done by using a pointer to the same
`metric.FieldValue` struct.
The struct type still externally exposes its string so that it can be referred
to in value function callbacks by "custom" metrics. (Though there are no
current uses of callback metrics with fields.)
PiperOrigin-RevId: 527030738
This optimizes both increments and lookup operations.
It does so using the following:
- For metrics of potential cardinality larger than 48, it will switch to using
a map rather than linear search for mapping field value combinations to the
index that combination corresponds to in the flattened list of values.
For metrics of cardinality 48 or smaller, linear search is still used as it
is still faster (and also still faster than binary search), as determined by
benchmarks.
- All field values are checked for pointer uniqueness (i.e. the pointer to the
start of each field value string must be unique). This is then used for
faster matching: instead of comparing whole strings (and needing to hash
them, in the case of doing map-based lookups), it compares pointer values.
In the context of this metric library, because all field values must be
pre-declared ahead of time, keeping references to these pre-declared strings
should always be possible. This is enforced: it will `panic` if the metric
user does not do this. In practice, this is easy to do by using `const`
strings for all metric values. This change does just that for existing
metrics with string fields.
From benchmarks, this speeds up the time to take a snapshot of existing
metrics by -8.35%. With the unimplemented syscall counter metric, this
optimization reduces the slowdown of adding this metric from +4,250% to
a still-large but much more manageable +290%. A further optimization
(cl/524419591) will reduce this overhead further before re-introducing the
unimplemented syscall counter metric.
PiperOrigin-RevId: 526134756
syshandler can be interrupted by SIGCHLD. Here are two separate cases. The first
one is when the interrupt are addressed to a context that has triggered
syshanlder. In this case, the interrupt can be ignored, because the context
is switching to the sentry. Another case is when syshandler is resuming a new
context. It means we need to stop resuming it and return the context back to
the sentry. The good thing is that the context state is up to date, and so
sighandler can do its job ignoring a state from a signal frame.
Reported-by: [email protected]
PiperOrigin-RevId: 520986791
The idea of the handshake timeout is to see if here is any free active thread.
In addition, here are a few fixes that prevent waking up too many threads.
PiperOrigin-RevId: 519871285
In general it is probably a good idea to set a timeout on any futex waits that
the sentry is doing. For now just output some helpful logs about what the shared
memory looks like; in the future we may want to do something more useful on
ETIMEDOUT events.
PiperOrigin-RevId: 518919966
With context decoupling off, TLS was not initialized properly because upon
creation of a sysmsg thread the sighandler overwrote TLS with 0. The fix for
this is to write the correct TLS only _after_ the sysmsg thread is initialized.
With context decoupling on, retrieveArchSpecificState was not being used, which
means that TLS was not saved to the sentry at all. So in this case, sysmsg
threads would initially have the correct TLS value, but as soon as it changed
during runtime it would become incorrect.
Reported-by: [email protected]
PiperOrigin-RevId: 518626789
The spinning queue is a queue of spinning threads. It solves the
fragmentation problem. The idea is to minimize the number of threads
processing requests. We can't control how system threads are scheduled, so
can't distribute requests efficiently. The spinning queue emulates virtual
threads sorted by their spinning time.
PiperOrigin-RevId: 518470754
This change introduces an abstraction for most accesses to shared thread-context
memory. In general, there are very few cases where accessing this memory is not
supposed to be atomic, so it makes sense to abstract these accesses into
getters/setters that perform the actions atomically. After this change, we
should treat most direct accesses through sharedContext.shared as suspect.
Additionally this cleanup allows the new sharedContext instance to become the
context interruptor. When doing this it is no longer required to use locks, as
was done in context.NotifyInterrupt.
PiperOrigin-RevId: 517166307
This is the initial implementation of the systrap context queue via a ringbuffer
in shared memory between stub threads and the sentry.
In this new model there is no longer a bound sysmsg thread for every context;
instead each subprocess starts with one initial sysmsg thread, which starts
polling the context queue for new contexts arriving from the sentry. If the
sentry detects that contexts are spending too much time in the context queue
without being processed, it will create new sysmsg threads or wake sleeping
ones. Tangentially, sysmsg threads will go to sleep if they spend too much time
busy looping without new context arrivals.
This model does not yet take into account the full load of the host system or
even multiple subprocesses in the same sandbox. Multiple overloaded subprocesses
are liable to make each other run slower by kicking sysmsg threads more often
than they need to; this will be remedied in follow up CLs.
PiperOrigin-RevId: 516680504
This is a relatively benign data race that's possible when two of the last
remaining contexts are calling s.unregisterContext at the same time, and both
decrement s.numContexts. One continues to release() the subprocess which puts it
into the available pool, but the other one has yet to read s.released. Then,
since the subprocess is in the available pool it can be retrieved with
fetchAvailable, which did not lock s.mu, which is where the data race happens,
because fetchAvailable flips s.released but one of the exiting contexts has yet
to read it.
The proper fix for this is to start holding references onto the subprocess. We
cannot reuse the subprocess while any systrap.contexts are still holding onto
sysmsg.ThreadContexts, so each context get's a reference. Each subprocess is
held by a MemoryManager as an AddressSpace interface, which calls Release on the
subprocess once.
This CL also removes subprocessPool.active because it is unnecessary at this
moment.
PiperOrigin-RevId: 516272892
Also add interrupt handling for context decoupling.
Previously syshandler interrupts would be retriggered no matter if the interrupt
arrived before the switch to sentry or after. We only need to handle the case of
it arriving after.
Additionally this CL introduces interrupt handling for the decoupled context
mode, by making interrupts target task contexts rather than sysmsg threads.
PiperOrigin-RevId: 515065101
This moves the initialization of `cpuid.hostFeatureSet` out of package-level
`init` and instead moves it to an explicit `cpuid.Initialize()` function.
On AMD64, this saves about 512KiB of heap memory that would otherwise always
be live.
PiperOrigin-RevId: 514896323
Rewrite the syshandler assembly routine to save the full state of user threads,
like the sighandler would. With fpstate, it does so by writing straight to the
thread context struct, so there is no need to do an intermediate copy.
PiperOrigin-RevId: 514751894
Saves task context state to the separate context memory region which is mapped
to all subprocess sysmsg threads, instead of always saving the context to the
thread-specific sysmsg.
When context decoupling is disabled fpstate is not saved to this region, but
GP registers and signal info are.
PiperOrigin-RevId: 514432596
For all trivial and zero frame-sized functions, we now require an explicit
NOFRAME annotation as the heuristic has changed. See go.dev/cl/466316.
Most of these functions do not *require* NOFRAME, but this change encodes
the existing behavior in order to avoid accidental bugs or regressions.
PiperOrigin-RevId: 513946210
Introduces what a ThreadContext struct is in the context of systrap. It
makes the mappings of the region where the contexts will be stored into both the
sentry and the address space of stub processes.
PiperOrigin-RevId: 513913793
This is a quick and dirty way to activate context decoupling related changes.
Will be removed once context decoupling is finalized.
PiperOrigin-RevId: 513854004
