This partially reverts cl/578969556, but implements devtmpfs using fsimpl/dev
(added by that CL).
Note that the behavior of "devtmpfs" differs compared to before cl/578969556.
Container runtime specs typically specify a tmpfs mount at /dev, which the
container runtime is required to prepopulate with certain device files
(https://github.com/opencontainers/runtime-spec/blob/main/config-linux.md#default-devices).
Prior to cl/578969556, runsc did so by silently replacing tmpfs mounts at /dev
with devtmpfs mounts. After that CL, runsc does so by silently replacing tmpfs
mounts at /dev with fsimpl/dev mounts. The distinction is that devtmpfs is a
singleton whereas fsimpl/dev is not, so in a multi-container sandbox, all
containers shared the contents of /dev before cl/578969556, but not after that
CL; this change was necessary due to differences in GPU/TPU accessibility
between containers, and is also more consistent with runc (which also creates
separate tmpfs mounts for /dev as specified).
As a side effect, explicit devtmpfs mounts shared the same filesystem as every
container's /dev before cl/578969556. Since the change to container /dev won't
be reverted, our options now are:
- All devtmpfs mounts share a single filesystem, which is distinct from any
container's /dev.
- Each devtmpfs mount gets a distinct filesystem.
This CL chooses the former option for greater similarity to Linux devtmpfs
semantics. (In runc, explicit devtmpfs mounts share a single filesystem, which
is the *host's* /dev.)
PiperOrigin-RevId: 589021563
Our devtmpfs implementation uses the same tmpfs filesystem instance for all
devtmpfs mounts in the sandbox. This would mean that devices mounted in a
container are visible and accessible to all other containers in the sandbox.
With GPU/TPU, the contents of devtmpfs can be different for different
containers within the same sandbox. So it is important to not share the same
devtmpfs contents.
It is better to drop support for devtmpfs, than to implement it incorrectly.
Instead, this change introduces a new dummy filesystem type named `dev`. This
filesystem can not be mounted or listed by the application. This filesystem
creates a new tmpfs instance on GetFilesystem() and populates it with all the
device files.
PiperOrigin-RevId: 578969556
Readonly mounts or readonly path mappings will return EROFS or EPERM even if
the file exists at that location. So relying on MkdirAt() to return EEXIST can
yield incorrect results.
Instead call MkdirAllAt(), which uses StatAt() to check for existence. This
yields accurate results.
PiperOrigin-RevId: 539228542
Fix TODO comments referring to incorrect issue numbers. Also fix the link in
issue reviver comments to include the right url fragment.
PiperOrigin-RevId: 373491821
Inode number consistency checks are now skipped in save/restore tests for
reasons described in greatest detail in StatTest.StateDoesntChangeAfterRename.
They pass in VFS1 due to the bug described in new test case
SimpleStatTest.DifferentFilesHaveDifferentDeviceInodeNumberPairs.
Fixes#1663
PiperOrigin-RevId: 338776148
Singleton filesystem like devpts and devtmpfs have a single filesystem shared
among all mounts, so they acquire a "self-reference" when initialized that
must be released when the entire virtual filesystem is released at sandbox
exit.
PiperOrigin-RevId: 336828852
This lets us create "synthetic" mountpoint directories in ReadOnly mounts
during VFS setup.
Also add context.WithMountNamespace, as some filesystems (like overlay) require
a MountNamespace on ctx to handle vfs.Filesystem Operations.
PiperOrigin-RevId: 327874971
Both have analogues in Linux:
* struct file_system_type has a char *name field.
* struct super_block keeps a pointer to the file_system_type.
These fields are necessary to support the `filesystem type` field in
/proc/[pid]/mountinfo.
PiperOrigin-RevId: 303434063
- Added fsbridge package with interface that can be used to open
and read from VFS1 and VFS2 files.
- Converted ELF loader to use fsbridge
- Added VFS2 types to FSContext
- Added vfs.MountNamespace to ThreadGroup
Updates #1623
PiperOrigin-RevId: 295183950
Fabricio VoznikaandgVisor bot
Jamie LiuandgVisor bot
Ayush RanjanandgVisor bot
Andrei VaginandgVisor bot
Adin ScannellandgVisor bot
Kevin KrakauerandgVisor bot
Ian LewisandgVisor bot
Dean DengandgVisor bot
Nicolas LacasseandgVisor bot
Nayana BidariandgVisor bot