linuxerr.IsValid just checks if the errno is less than the max possible errno
value. syserr.IsValid additionally checks if the errno can be translated by the
syserr package.
Furthermore, drop the usage of linuxerr.TranslateError(), which only checks
against a map with 3 entries of sentry-internal errors. Earlier, connError()
would always fail at this step and end up returning linuxerr.EINVAL even if the
errno being returned is valid.
Reported-by: syzbot+180b8537798c091bf9fd@syzkaller.appspotmail.com
PiperOrigin-RevId: 680021716
FUSE is supposed to receive an error code corresponding to Linux errors, but
since it's running in another process we can't guarantee that. So instead of
propogating a nonsensical error code (that can lead, in some cases, to panics),
warn and convert the failure to EINVAL.
PiperOrigin-RevId: 660274364
Adapted from cl/630063475.
This causes FUSE tests involving submounts to fail, because fuse.inode.Valid()
just returns false (fails revalidation) after the entry time expires, causing
all submounts to be unmounted; change it to perform revalidation instead, a la
Linux's fs/fuse/dir.c:fuse_dentry_revalidate(). This in turn requires that we
plumb the dentry's parent and name through kernfs.Inode.Valid().
PiperOrigin-RevId: 630476483
This allows for external information to be passed to restore code.
Similar to c087777e37 ("Plumb restore context to afterLoad()").
Updates #1956.
PiperOrigin-RevId: 614125262
Fixes#9932.
When Go is able to detect `io.Copy()` from a TCP socket or `AF_UNIX` stream
socket to a TCP socket, it attempts to implement the copy as a `splice(2)` from
the source to a pipe, followed by a `splice(2)` from the pipe to the
destination [1] (since `splice(2)` requires that one of the endpoints be a
pipe); the size of the pipe is set to 1 MB [2] (from a default of 64 KB [3]) to
reduce the number of splice syscalls required. In gVisor, a bug causes each
splice syscall from pipe to TCP socket to repeatedly read the *first* 64 KB [4]
of the pipe's data (when it contains more than 64 KB of data) rather than
*successive* chunks of 64 KB.
To fix this, advance pipe state by calling `Pipe.consumeLocked()` immediately
after `Pipe.peekLocked()`. Also defensively check that such FDs call
`Pipe.(usermem.IO)` methods on sequential addresses, and change
`fuse.deviceFD.Write()` to have this property.
[1] Go: `net/tcpsock_posix.go:TCPConn.readFrom()` =>
`net/splice_linux.go:splice()` => `internal/poll/splice_linux.go:Splice()`
[2] Go: `internal/poll/splice_linux.go:newPipe()` => `maxSpliceSize`
[3] `pkg/kernel/pipe/pipe.go:DefaultPipeSize`
[4] `pkg/tcpip/transport/tcp/endpoint.go:endpoint.Write()` =>
`endpoint.queueSegment()` => `endpoint.readFromPayloader()` =>
`pkg/buffer/buffer.go:Buffer.WriteFromReader()` =>
`pkg/buffer/chunk.go:MaxChunkSize`
PiperOrigin-RevId: 603151951
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
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>
If FUSE connection does not support atomic O_TRUNC and application calls
open(O_TRUNC), FUSE should truncate the file *first* (without a file handle)
and then subsequently open the file with O_TRUNC filtered out.
We were truncating the file after open(). There were 2 issues with it:
1. We were using the inode's file handle, which may be invalid at this point
because it is donated to the first FD (to save an open(2) RPC I believe)
and that FD can close it.
2. The truncate() was being done with fhOptions.useFh = true. However,
sometimes the file handle might be read-only causing truncate to fail.
Fixed both issues by moving the truncate above open() and making it not use any
file handles.
PiperOrigin-RevId: 567658664
These inodes can never be part of a filesystem tree. They are nameless and
never have a parent.
This allows us to avoid taking a lock in kernfs.InotifyWithParent for such
anonymous inodes.
PiperOrigin-RevId: 538823227
Andrei VaginandgVisor bot
Jamie LiuandgVisor bot
Ayush RanjanandgVisor bot
Nayana BidariandgVisor bot
Nicolas LacasseandgVisor bot
Kevin KrakauerandgVisor bot
Lucas ManningandgVisor bot
dongjinlong
Fabricio VoznikaandgVisor bot
Andrei Vagin
Adin ScannellandgVisor bot