Age | Commit message (Collapse) | Author |
|
|
|
In VFS2, imported file descriptors are stored in a kernfs-based filesystem.
Upon calling ImportFD, the host fd can be accessed in two ways:
1. a FileDescription that can be added to the FDTable, and
2. a Dentry in the host.filesystem mount, which we will want to access through
magic symlinks in /proc/[pid]/fd/.
An implementation of the kernfs.Inode interface stores a unique host fd. This
inode can be inserted into file descriptions as well as dentries.
This change also plumbs in three FileDescriptionImpls corresponding to fds for
sockets, TTYs, and other files (only the latter is implemented here).
These implementations will mostly make corresponding syscalls to the host.
Where possible, the logic is ported over from pkg/sentry/fs/host.
Updates #1672
PiperOrigin-RevId: 299417263
|
|
|
|
When list elements are removed from a list but not discarded, it becomes
important to invalidate the references they hold to their former
neighbors to prevent memory leaks.
PiperOrigin-RevId: 299412421
|
|
|
|
PiperOrigin-RevId: 299405855
|
|
|
|
PiperOrigin-RevId: 299405663
|
|
|
|
From RFC 793 s3.9 p61 Event Processing:
CLOSE Call during TIME-WAIT: return with "error: connection closing"
Fixes #1603
PiperOrigin-RevId: 299401353
|
|
|
|
If the NIC has a valid IPv6 address assigned, use it as the
source address for outgoing NDP Router Solicitation packets.
Test: stack_test.TestRouterSolicitation
PiperOrigin-RevId: 299398763
|
|
|
|
Useful for logs to print the string representation of the value
instead of the integer value.
PiperOrigin-RevId: 299356847
|
|
|
|
Adds an oom_score_adj and oom_score proc file stub. oom_score_adj accepts
writes of values -1000 to 1000 and persists the value with the task. New tasks
inherit the parent's oom_score_adj.
oom_score is a read-only stub that always returns the value '0'.
Issue #202
PiperOrigin-RevId: 299245355
|
|
|
|
PiperOrigin-RevId: 299238067
|
|
|
|
PiperOrigin-RevId: 299233818
|
|
|
|
By putting slices into the pool, the slice header escapes. This can be avoided
by not putting the slice header into the pool.
This removes an allocation from the TCP segment send path.
PiperOrigin-RevId: 299215480
|
|
A parser of test results doesn't expect to see any extra messages.
PiperOrigin-RevId: 298966577
|
|
|
|
PiperOrigin-RevId: 298941855
|
|
gofer.dentryReadWriter.WriteFromBlocks was not updating
gofer.dentry.size after a write operation that skips the
cache.
Updates #1198
PiperOrigin-RevId: 298708646
|
|
|
|
Properly discard segments from the segment heap.
PiperOrigin-RevId: 298704074
|
|
|
|
The support of PTRACE_SYSEMU on arm64 was added in the 5.3 kernel,
so we can be sure that the current version is higher that 5.3.
And this change moves vsyscall seccomp rules to the arch specific file,
because vsyscall isn't supported on arm64.
PiperOrigin-RevId: 298696493
|
|
|
|
PiperOrigin-RevId: 298690552
|
|
|
|
Ensures that all access to TransportEndpointInfo.ID is either:
* In a function ending in a Locked suffix.
* While holding the appropriate mutex.
This primary affects the checkV4Mapped method on affected endpoints, which has
been renamed to checkV4MappedLocked. Also document the method and change its
argument to be a value instead of a pointer which had caused some awkwardness.
This race was possible in the udp and icmp endpoints between Connect and uses
of TransportEndpointInfo.ID including in both itself and Bind.
The tcp endpoint did not suffer from this bug, but benefited from better
documentation.
Updates #357
PiperOrigin-RevId: 298682913
|
|
|
|
PiperOrigin-RevId: 298476533
|
|
|
|
PiperOrigin-RevId: 298451319
|
|
|
|
A deadlock may occur if a write lock on a RWMutex is blocked between
nested read lock attempts as the inner read lock attempt will be
blocked in this scenario.
Example (T1 and T2 are differnt goroutines):
T1: obtain read-lock
T2: attempt write-lock (blocks)
T1: attempt inner/nested read-lock (blocks)
Here we can see that T1 and T2 are deadlocked.
Tests: Existing tests pass.
PiperOrigin-RevId: 298426678
|
|
|
|
PiperOrigin-RevId: 298405064
|
|
|
|
DATA RACE in netstack.(*SocketOperations).fetchReadView
Write at 0x00c001dca138 by goroutine 1001:
gvisor.dev/gvisor/pkg/sentry/socket/netstack.(*SocketOperations).fetchReadView()
pkg/sentry/socket/netstack/netstack.go:418 +0x85
gvisor.dev/gvisor/pkg/sentry/socket/netstack.(*SocketOperations).coalescingRead()
pkg/sentry/socket/netstack/netstack.go:2309 +0x67
gvisor.dev/gvisor/pkg/sentry/socket/netstack.(*SocketOperations).nonBlockingRead()
pkg/sentry/socket/netstack/netstack.go:2378 +0x183d
Previous read at 0x00c001dca138 by goroutine 1111:
gvisor.dev/gvisor/pkg/sentry/socket/netstack.(*SocketOperations).Ioctl()
pkg/sentry/socket/netstack/netstack.go:2666 +0x533
gvisor.dev/gvisor/pkg/sentry/syscalls/linux.Ioctl()
Reported-by: syzbot+d4c3885fcc346f08deb6@syzkaller.appspotmail.com
PiperOrigin-RevId: 298387377
|
|
|
|
PiperOrigin-RevId: 298380654
|
|
|
|
PiperOrigin-RevId: 297982488
|
|
|
|
This is needed for syzkaller to proper classify issues.
Right now, all watchdog issues are duped to one with the
subject "panic: Sentry detected stuck task(s). See stack
trace and message above for more details".
PiperOrigin-RevId: 297975363
|