A tty inode was kept alive by a single ownership chain: the stdio file
description's reference on the import-time dentry. Everything else that used
the inode referred to it uncounted: a file description opened via /dev/tty
pins only the devtmpfs dentry, and the controlling-terminal association
(ThreadGroup.tty) is a bare pointer.
PiperOrigin-RevId: 962479941
The TTYOperations for a donated host TTY were on the TTYFileDescription, but
that scopes them per-FD, when they should be scoped per-inode.
This CL moves the TTYOperations logic to the host inode struct, rather than the
TTYFileDescription. It also renames TTYOperations.Open ->
TTYOperations.TTYOpen, to avoid a naming collision with kernfs.inodeOpen.
As a result, opening a TTY (like via /dev/tty) always goes through inode.open,
thus creating a new TTYFileDescrption every time, whereas previously we
incorrectly returned the same TTYFileDescription each time.
Fixes#11644
PiperOrigin-RevId: 752856291
The /dev/tty acts as a replica for the current thread group's controlling
terminal.
In a follow-up, I will make /dev/tty work for donated host ttys.
Updates #10925
PiperOrigin-RevId: 681629892
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
This is in compliance with VFS1. See pkg/sentry/fs/dev/tty.go in the struct
ttyInodeOperations.
Fixes the failure of python runtime test_ioctl.
Updates #3515
PiperOrigin-RevId: 327042758