Age | Commit message (Collapse) | Author |
|
PiperOrigin-RevId: 345178956
|
|
kernel.Task can only be used as context.Context by that Task's task goroutine.
This is violated in at least two places:
- In any case where one thread accesses the /proc/[tid] of any other thread,
passing the kernel.Task for [tid] as the context.Context is incorrect.
- Task.rebuildTraceContext() may be called by Kernel.RebuildTraceContexts()
outside the scope of any task goroutine.
Fix these (as well as a data race on Task.traceContext discovered during the
course of finding the latter).
PiperOrigin-RevId: 342174404
|
|
PiperOrigin-RevId: 340536306
|
|
This PR implements /proc/[pid]/mem for `pkg/sentry/fs` (refer to #2716) and `pkg/sentry/fsimpl`.
@majek
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/4060 from lnsp:proc-pid-mem 2caf9021254646f441be618a9bb5528610e44d43
PiperOrigin-RevId: 339369629
|
|
PiperOrigin-RevId: 334478850
|
|
PiperOrigin-RevId: 332760843
|
|
In Linux, FDSize is fs/proc/array.c:task_state() => struct fdtable::max_fds,
which is set to the underlying array's length in fs/file.c:alloc_fdtable().
Follow-up changes:
- Remove FDTable.GetRefs() and FDTable.GetRefsVFS2(), which are unused.
- Reset FDTable.used to 0 during restore, since the subsequent calls to
FDTable.setAll() increment it again, causing its value to be doubled. (After
this CL, FDTable.used is only used to avoid reallocation in FDTable.GetFDs(),
so this fix is not very visible.)
PiperOrigin-RevId: 331588190
|
|
- Merges aleksej-paschenko's with HEAD
- Adds vfs2 support for ip_forward
|
|
/proc/sys/net/ipv4/tcp_recovery is used to enable RACK loss
recovery in TCP.
PiperOrigin-RevId: 325157807
|
|
context is passed to DecRef() and Release() which is
needed for SO_LINGER implementation.
PiperOrigin-RevId: 324672584
|
|
PiperOrigin-RevId: 310179277
|
|
- Fix defer operation ordering in kernfs.Filesystem.AccessAt()
- Add AT_NULL entry in proc/pid/auvx
- Fix line padding in /proc/pid/maps
- Fix linux_dirent serialization for getdents(2)
- Remove file creation flags from vfs.FileDescription.statusFlags()
Updates #1193, #1035
PiperOrigin-RevId: 307704159
|
|
PiperOrigin-RevId: 305807868
|
|
Updates #164
PiperOrigin-RevId: 305544029
|
|
This required minor restructuring of how system call tables were saved
and restored, but it makes way more sense this way.
Updates #2243
|
|
PiperOrigin-RevId: 304508083
|
|
- Make oomScoreAdj a ThreadGroup field (Linux: signal_struct::oom_score_adj).
- Avoid deadlock caused by Task.OOMScoreAdj()/SetOOMScoreAdj() locking Task.mu
and TaskSet.mu in the wrong order (via Task.ExitState()).
PiperOrigin-RevId: 300814698
|
|
Issue #1833
PiperOrigin-RevId: 299998105
|
|
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
|
|
Each mount is holds a reference on a root Dirent, but the mount itself may
live beyond it's own reference. This means that a call to Root() can come
after the associated reference has been dropped.
Instead of introducing a separate layer of references for mount objects,
we simply change the Root() method to use TryIncRef() and allow it to return
nil if the mount is already gone. This requires updating a small number of
callers and minimizes the change (since VFSv2 will replace this code shortly).
PiperOrigin-RevId: 297174230
|
|
TCP/IP will work with netstack networking. hostinet doesn't work, and sockets
will have the same behavior as it is now.
Before the userspace is able to create device, the default loopback device can
be used to test.
/proc/net and /sys/net will still be connected to the root network stack; this
is the same behavior now.
Issue #1833
PiperOrigin-RevId: 296309389
|
|
- 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
|
|
These were out-of-band notes that can help provide additional context
and simplify automated imports.
PiperOrigin-RevId: 293525915
|
|
Because the abi will depend on the core types for marshalling (usermem,
context, safemem, safecopy), these need to be flattened from the sentry
directory. These packages contain no sentry-specific details.
PiperOrigin-RevId: 291811289
|
|
PiperOrigin-RevId: 291745021
|
|
Some files were missing the last line break.
PiperOrigin-RevId: 290808898
|
|
Java 11 parses /proc/self/mountinfo for cgroup information. Java 11.0.4 uses
the mount path to determine what cgroups existed, but Java 11.0.5 reads the
cgroup names from the superblock options.
This CL adds the cgroup name to the superblock options if the filesystem type
is "cgroup". Since gVisor doesn't actually support cgroups yet, we just infer
the cgroup name from the path.
PiperOrigin-RevId: 290434323
|
|
PiperOrigin-RevId: 290198756
|
|
There is a lot of code duplication for VFSv2 and this
serves as remind to keep the copies in sync.
Updates #1195
PiperOrigin-RevId: 290139234
|
|
Except for one under /proc/sys/net/ipv4/tcp_sack.
/proc/pid/* is still incomplete.
Updates #1195
PiperOrigin-RevId: 290120438
|
|
* Rename syncutil to sync.
* Add aliases to sync types.
* Replace existing usage of standard library sync package.
This will make it easier to swap out synchronization primitives. For example,
this will allow us to use primitives from github.com/sasha-s/go-deadlock to
check for lock ordering violations.
Updates #1472
PiperOrigin-RevId: 289033387
|
|
PiperOrigin-RevId: 286248378
|
|
PiperOrigin-RevId: 284038840
|
|
PiperOrigin-RevId: 283630669
|
|
This allows writable proc and devices files to be opened with O_CREAT|O_TRUNC.
This is encountered most frequently when interacting with proc or devices files
via the command line.
e.g. $ echo 8192 1048576 4194304 > /proc/sys/net/ipv4/tcp_rmem
Also adds a test to test the behavior of open(O_TRUNC), truncate, and ftruncate
on named pipes.
Fixes #1116
PiperOrigin-RevId: 282677425
|
|
|
|
PiperOrigin-RevId: 276380008
|
|
PiperOrigin-RevId: 275139066
|
|
This proc file reports routing information to applications inside the
container.
Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com>
Change-Id: I498e47f8c4c185419befbb42d849d0b099ec71f3
|
|
This proc file contains statistics according to [1].
[1] https://tools.ietf.org/html/rfc2013
Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com>
Change-Id: I9662132085edd8a7783d356ce4237d7ac0800d94
|
|
PiperOrigin-RevId: 272522508
|
|
Right now, we can find more than one process with the 1 PID in /proc.
$ for i in `seq 10`; do
> unshare -fp sleep 1000 &
> done
$ ls /proc
1 1 1 1 12 18 24 29 6 loadavg net sys version
1 1 1 1 16 20 26 32 cpuinfo meminfo self thread-self
1 1 1 1 17 21 28 36 filesystems mounts stat uptime
PiperOrigin-RevId: 272506593
|
|
Fixes: #829
Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com>
Signed-off-by: Jielong Zhou <jielong.zjl@antfin.com>
|
|
They are no-ops, so the standard rule works fine.
PiperOrigin-RevId: 268776264
|
|
PiperOrigin-RevId: 266229756
|
|
Previously we were representing socket addresses as an interface{},
which allowed any type which could be binary.Marshal()ed to be used as
a socket address. This is fine when the address is passed to userspace
via the linux ABI, but is problematic when used from within the sentry
such as by networking procfs files.
PiperOrigin-RevId: 262460640
|
|
PiperOrigin-RevId: 258479216
|
|
This proc file reports the stats of interfaces. We could use ifconfig
command to check the result.
Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com>
Change-Id: Ia7c1e637f5c76c30791ffda68ee61e861b6ef827
COPYBARA_INTEGRATE_REVIEW=https://gvisor-review.googlesource.com/c/gvisor/+/18282/
PiperOrigin-RevId: 258303936
|
|
PiperOrigin-RevId: 257855479
|
|
This renames FDMap to FDTable and drops the kernel.FD type, which had an entire
package to itself and didn't serve much use (it was freely cast between types,
and served as more of an annoyance than providing any protection.)
Based on BenchmarkFDLookupAndDecRef-12, we can expect 5-10 ns per lookup
operation, and 10-15 ns per concurrent lookup operation of savings.
This also fixes two tangential usage issues with the FDMap. Namely, non-atomic
use of NewFDFrom and associated calls to Remove (that are both racy and fail to
drop the reference on the underlying file.)
PiperOrigin-RevId: 256285890
|