Files
visor/test
Shailend ChandandgVisor bot d3bcea91b0 gofer: Take refs when adopting a cached endpoint-bearing inode
When an AF_UNIX socket is bound to a path, the resulting BoundEndpoint is
stored on the gofer inode, and other processes reach it by path: they walk
to the dentry, then pull the endpoint off its inode and connect. Crucially,
a bound socket stays connectable even when no file descriptor is holding
that path open.

The gofer refcounting invariant is: "An additional reference is held on all
synthetic dentries, and on all dentries for which endpoint is non-nil, until
they are unlinked or invalidated."

This purpose of this invariant is for a host-backed bound UDS to stay
resolvable by path even when no FD holds it. A gofer dentry at refs == 0 is
eligible for reclaim; reclaiming it tears down the inode and drops the
HostBoundEndpoint (and its host FD). So the filesystem pins every endpoint-
bearing dentry with one extra ref, held from bind until the name goes away.

This extra ref is dropped unconditionally, guarded only by `endpoint != nil`
in many places: unlinkAt, RenameAt, revalidation/invalidation, filesystem
teardown etc. (These drop paths assume that the invariant holds.)

To establish the invariant the extra ref is taken in the bind paths sure, but
we were missing a reference increment for a dentry that later comes to point
at the same endpoint-bearing inode. This can happen either due to a hard link
or another walk that lands on the same inode.

PiperOrigin-RevId: 966116353
2026-08-17 12:28:06 -07:00
..
2025-08-28 14:04:12 -07:00
2026-07-30 15:51:37 -07:00
2026-08-04 10:59:32 -07:00
2025-01-29 21:16:51 -08:00

Tests

The tests defined under this path are verifying functionality beyond what unit tests can cover, e.g. integration and end to end tests. Due to their nature, they may need extra setup in the test machine and extra configuration to run.

  • syscalls: system call tests use a local runner, and do not require additional configuration in the machine.
  • integration: defines integration tests that uses docker run to test functionality.
  • image: basic end to end test for popular images. These require the same setup as integration tests.
  • root: tests that require to be run as root. These require the same setup as integration tests.
  • util: utilities library to support the tests.

For the above noted cases, the relevant runtime must be installed via runsc install before running. Just note that they require specific configuration to work. This is handled automatically by the test scripts in the scripts directory and they can be used to run tests locally on your machine. They are also used to run these tests in kokoro.

Example:

To run image and integration tests, run:

make docker-tests

To run root tests, run:

make sudo TARGETS=test/root:root_test

There are a few other interesting variations for image and integration tests:

  • overlay: sets writable overlay inside the sentry
  • hostnet: configures host network passthrough, instead of netstack
  • kvm: runsc the test using the KVM platform, instead of systrap

The test will build runsc, configure it with your local docker, restart dockerd, and run tests. The location for runsc logs is printed to the output.