| Age | Commit message (Collapse) | Author |
|---|
|
Previously, mount could discover a hierarchy being destroyed
concurrently, which resulted in mount attempting to take a ref on an
already destroyed cgroupfs.
Reported-by: syzbot+062c0a67798a200f23ee@syzkaller.appspotmail.com
PiperOrigin-RevId: 374959054
|
|
Before this change, we would silently drop packets when link resolution
failed. This change brings us into line with RFC 792 (IPv4) and RFC 4443 (IPv6),
both of which specify that gateways should return an ICMP error to the sender
when link resolution fails.
PiperOrigin-RevId: 374699789
|
|
This metric is replaced by /cloud/gvisor/sandbox/sentry/suspicious_operations
metric with field value opened_write_execute_file.
PiperOrigin-RevId: 374509823
|
|
Weirdness metric will replace the below two metrics:
- watchdog/stuck_startup_detected
- watchdog/stuck_tasks_detected
PiperOrigin-RevId: 373895696
|
|
The new metric contains fields and will replace the below existing metric:
- opened_write_execute_file
PiperOrigin-RevId: 373884604
|
|
O_PATH is now implemented in vfs2.
Fixes #2782.
PiperOrigin-RevId: 373861410
|
|
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt:
/proc/sys/net/ipv4/* Variables:
ip_forward - BOOLEAN
0 - disabled (default)
not 0 - enabled
Forward Packets between interfaces.
This variable is special, its change resets all configuration
parameters to their default state (RFC1122 for hosts, RFC1812
for routers)
/proc/sys/net/ipv4/ip_forward only does work when its value is changed
and always returns the last written value. The last written value may
not reflect the current state of the netstack (e.g. when `ip_forward`
was written a value of "1" then disable forwarding on an interface)
so there is no need for sentry to probe netstack to get the current
forwarding state of interfaces.
```
~$ cat /proc/sys/net/ipv4/ip_forward
0
~$ sudo bash -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
~$ cat /proc/sys/net/ipv4/ip_forward
1
~$ sudo sysctl -a | grep ipv4 | grep forward
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.eno1.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.wlp1s0.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0
~$ sudo sysctl -w net.ipv4.conf.wlp1s0.forwarding=0
net.ipv4.conf.wlp1s0.forwarding = 0
~$ sudo sysctl -a | grep ipv4 | grep forward
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.eno1.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.wlp1s0.forwarding = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0
~$ cat /proc/sys/net/ipv4/ip_forward
1
~$ sudo bash -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
~$ sudo sysctl -a | grep ipv4 | grep forward
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.eno1.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.wlp1s0.forwarding = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0
~$ sudo bash -c "echo 0 > /proc/sys/net/ipv4/ip_forward"
~$ sudo sysctl -a | grep ipv4 | grep forward
sysctl: unable to open directory "/proc/sys/fs/binfmt_misc/"
net.ipv4.conf.all.forwarding = 0
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.eno1.forwarding = 0
net.ipv4.conf.lo.forwarding = 0
net.ipv4.conf.wlp1s0.forwarding = 0
net.ipv4.ip_forward = 0
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0
~$ cat /proc/sys/net/ipv4/ip_forward
0
```
In the above example we can see that writing "1" to
/proc/sys/net/ipv4/ip_forward configures the stack to be a router (all
interfaces are configured to enable forwarding). However, if we manually
update an interace (`wlp1s0`) to not forward packets,
/proc/sys/net/ipv4/ip_forward continues to return the last written value
of "1", even though not all interfaces will forward packets.
Also note that writing the same value twice has no effect; work is
performed iff the value changes.
This change also removes the 'unset' state from sentry's ip forwarding
data structures as an 'unset' ip forwarding value is the same as leaving
forwarding disabled as the stack is always brought up with forwarding
initially disabled; disabling forwarding on a newly created stack is a
no-op.
PiperOrigin-RevId: 373853106
|
|
Previously, registration was racy because we were publishing
hierarchies in the registry without fully initializing the underlying
filesystem. This led to concurrent mount(2)s discovering the partially
intialized filesystems and dropping the final refs on them which cause
them to be freed prematurely.
Reported-by: syzbot+13f54e77bdf59f0171f0@syzkaller.appspotmail.com
Reported-by: syzbot+2c7f0a9127ac6a84f17e@syzkaller.appspotmail.com
PiperOrigin-RevId: 373824552
|
|
...to make it clear to callers that all interfaces are updated with the
forwarding flag and that future NICs will be created with the new
forwarding state.
PiperOrigin-RevId: 373618435
|
|
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
|
|
Before this change, we would silently drop packets when the packet was too
big to be sent out through the NIC (and, for IPv4 packets, if DF was set).
This change brings us into line with RFC 792 (IPv4) and RFC 4443 (IPv6),
both of which specify that gateways should return an ICMP error to the sender
when the packet can't be fragmented.
PiperOrigin-RevId: 373480078
|
|
PiperOrigin-RevId: 373265454
|
|
PiperOrigin-RevId: 373221316
|
|
Currently, we process IPv6 extension headers when receiving packets
but not when forwarding them. This is fine for the most part, with
with one exception: RFC 8200 requires that we process the
Hop-by-Hop headers even while forwarding packets.
This CL adds that support by invoking the Hop-by-hop logic performed
when receiving packets during forwarding as well.
PiperOrigin-RevId: 373145478
|
|
PiperOrigin-RevId: 372608247
|
|
This patch is to solve problem that vCPU timer mess up when
adding vCPU dynamically on ARM64, for detailed information
please refer to:
https://github.com/google/gvisor/issues/5739
There is no influence on x86 and here are main changes for
ARM64:
1. create maxVCPUs number of vCPU in machine initialization
2. we want to sync gvisor vCPU number with host CPU number,
so use smaller number between runtime.NumCPU and
KVM_CAP_MAX_VCPUS to be maxVCPUS
3. put unused vCPUs into architecture-specific map initialvCPUs
4. When machine need to bind a new vCPU with tid, rather
than creating new one, it would pick a vCPU from map initalvCPUs
5. change the setSystemTime function. When vCPU number increasing,
the time cost for function setTSC(use syscall to set cntvoff) is
liner growth from around 300 ns to 100000 ns, and this leads to
the function setSystemTimeLegacy can not get correct offset
value.
6. initializing StdioFDs and goferFD before a platform to avoid
StdioFDs confects with vCPU fds
Signed-off-by: howard zhang <howard.zhang@arm.com>
|
|
This change implements /proc/cmdline with a basic faux command line
"BOOT_IMAGE=/vmlinuz-[version]-gvisor quiet" so apps that may expect
it do not receive errors.
Also tests for the existence of /proc/cmdline as part of the system
call test suite
PiperOrigin-RevId: 372462070
|
|
Before this change, we would silently drop packets when unable to determine a
route to the destination host. This change brings us into line with RFC 792
(IPv4) and RFC 4443 (IPv6), both of which specify that gateways should return
an ICMP error to the sender when unable to reach the destination.
Startblock:
has LGTM from asfez
and then
add reviewer ghanan
PiperOrigin-RevId: 372214051
|
|
PiperOrigin-RevId: 372020696
|
|
In order to resolve path names, fsSymlink.Readlink() may need to reenter
kernfs. Change the code so that kernfs.Inode.Readlink() is called without
locks and document the new contract.
PiperOrigin-RevId: 371770222
|
|
When a child is added to a parent (directory) dentry, both child and parent are
queued for checkCachingLocked(). Make sure that the parent is queued first
because the parent gained a ref and so could be removed from the LRU cache hence
making space for the new child. This could prevent an LRU cache eviction.
In practice, this did seem to help. ~800 RPCs were reduced while building
//absl/... (ABSL build benchmark). Evictions hurt in 2 ways - create renameMu
contention and destroy a possibly useful dentry which will have to be re-walked
and re-opened later.
Follow up fix for #5859.
PiperOrigin-RevId: 371509392
|
|
The root table physical page has to be mapped to not fault in iret or sysret
after switching into a user address space. sysret and iret are in the upper
half that is global and so page tables of lower levels are already mapped.
Fixes #5742
PiperOrigin-RevId: 371458644
|
|
If verification fails for translating mmapped memory, the content should
not be returned. This is not an issue for panic mode, but for error mode
we should return empty content along with the error.
PiperOrigin-RevId: 371393519
|
|
Originally we were making a WalkGetAttrOne RPC to confirm that a file does not
exist on the remote filesystem - when there was no cached information about the
existence of a dentry at that position.
This change avoids making that RPC and speculatively makes the
mkdir/mknod/linkat/symlink RPC. They will fail with EEXIST if a file exists at
that position as we want.
However the error ordering is important. Existence check comes before
writability check. So we make the existence check when the writability check
fails and give it precedence.
This change saves ~76,000 RPCs while building //absl/... (ABSL build benchmark).
That is 10% of all RPCs made while running that workload.
PiperOrigin-RevId: 371225633
|
|
PiperOrigin-RevId: 371216407
|
|
PiperOrigin-RevId: 371198372
|
|
PiperOrigin-RevId: 371163405
|
|
PiperOrigin-RevId: 371131985
|
|
PiperOrigin-RevId: 371015541
|
|
Co-Author: ayushranjan
PiperOrigin-RevId: 370785009
|
|
PiperOrigin-RevId: 370733869
|
|
The newly added Weirdness metric with fields should be used instead of them.
Simple query for weirdness metric: http://shortn/_DGNk0z2Up6
PiperOrigin-RevId: 370578132
|
|
PiperOrigin-RevId: 370181621
|
|
In https://github.com/google/gvisor/commit/f075522849fa a check to increase zero
to a minimum backlog length was removed from sys_socket.go to bring it in parity
with linux and then in tcp/endpoint.go we bump backlog by 1. But this broke
calling listen on a AF_UNIX socket w/ a zero backlog as in linux it does allow 1
connection even with a zero backlog.
This was caught by a php runtime test socket_abstract_path.phpt.
PiperOrigin-RevId: 369974744
|
|
Weirdness metric contains fields to track the number of clock fallback,
partial result and vsyscalls. This metric will avoid the overhead of
having three different metrics (fallbackMetric, partialResultMetric,
vsyscallCount).
PiperOrigin-RevId: 369970218
|
|
PiperOrigin-RevId: 369967629
|
|
With this change, GSO options no longer needs to be passed around as
a function argument in the write path.
This change is done in preparation for a later change that defers
segmentation, and may change GSO options for a packet as it flows
down the stack.
Updates #170.
PiperOrigin-RevId: 369774872
|
|
PiperOrigin-RevId: 369758655
|
|
PiperOrigin-RevId: 369724358
|
|
PiperOrigin-RevId: 369686285
|
|
If the host doesn't have TSC scaling feature, then scaling down TSC to
the lowest value will fail, and we will fall back to legacy logic
anyway, but we leave an ugly log message in host's kernel log.
kernel: user requested TSC rate below hardware speed
Instead, check for KVM_CAP_TSC_CONTROL when initializing KVM, and fall
back to legacy logic early if host's cpu doesn't support that.
Signed-off-by: Daniel Dao <dqminh89@gmail.com>
|
|
The gofer client's LRU cache has a default limit of 1000 dentries. Any attempt
to cache more dentries than that will make the LRU cache evict and destroy the
least recently used dentry. However, the eviction is expensive because it
requires holding fs.renameMu for writing - which in turn creates a lot of
contention. All filesystem operations that involve path traversal require
fs.renameMu for reading atleast.
Therefore, it is in our best interest to keep the cache small and clean.
When a dentry is inserted in the dentry tree, it grabs a ref on its parent for
its entire lifetime. Hence the parent is longer evictable (because refs > 0).
This change additionally calls checkCachingLocked on directories that have been
added to so that they can be removed from the LRU cache if needed.
This change implies that the LRU cache will only contain the leaves from the
filesystem tree which significantly reduces the LRU cache size and consequently
reduces the number of expensive LRU cache evictions.
> Why are opened dentries not removed from LRU cache?
When a file description is open(2)-ed, the file description holds a ref on its
dentry for its entire lifetime. However, calling checkCachingLocked() on opened
dentries actually ends up hurting performance. Applications usually open file
descriptors for a short duration. So upon close(2), the dentry is reinserted
into the cache anyway. So the precautionary work done in removing the opened
dentry from the cache went for waste as it did not really reduce an eviction.
Local benchmarking has shown that this change improves performance by 3-4%.
Across 6 runs, without this change it took 296.127 seconds to build runsc while
with this change it took only 285.136 seconds.
PiperOrigin-RevId: 369510494
|
|
Remote revalidating requires to update file size on every write
on a file opened with O_APPEND. If host FD exists, it can be
used to update the size and skip round trip to the gofer. With
this change, O_APPEND writes with remote revalidating is almost
as fast as exclusive mode:
BM_Append
VFS1 60.7us
VFS2 56.8us
VFS2 exclusive 14.2us
This change 15.8us
Updates #1792
PiperOrigin-RevId: 369486801
|
|
Fixes #2926, #674
PiperOrigin-RevId: 369457123
|
|
Currently the verity action is a global variable, which causes the same
action for all verity mounts, and is overwritten for each new verity
mount. Changed it to a member of verity fs.
PiperOrigin-RevId: 369348522
|
|
While using remote-validation, the vast majority of time spent during
FS operations is re-walking the path to check for modifications and
then closing the file given that in most cases it has not been
modified externally.
This change introduces a new 9P message called MultiGetAttr which bulks
query attributes of several files in one shot. The returned attributes are
then used to update cached dentries before they are walked. File attributes
are updated for files that still exist. Dentries that have been deleted are
removed from the cache. And negative cache entries are removed if a new
file/directory was created externally. Similarly, synthetic dentries are
replaced if a file/directory is created externally.
The bulk update needs to be carefull not to follow symlinks, cross mount
points, because the gofer doesn't know how to resolve symlinks and where
mounts points are located. It also doesn't walk to the parent ("..") to
avoid deadlocks.
Here are the results:
Workload VFS1 VFS2 Change
bazel action 115s 70s 28.8s
Stat/100 11,043us 7,623us 974us
Updates #1638
PiperOrigin-RevId: 369325957
|
|
Runsc build benchmark's mutex profile shows that we are wasting roughly 25-30
seconds waiting for filesystem.renameMu to get unlocked. Earlier
checkCachingLocked required the renameMu to be locked for writing. This is a
filesystem wide lock which puts all other filesystem operations on hold and
hence is really expensive. Something to note is that all path resolution
operations hold renameMu for reading.
With this change, we allow to check for caching without even holding renameMu.
This change introduces more fine grained locks (fs.cacheMu and dentry.cachingMu)
which protect the cache (removing the requirement to hold renameMu for writing
to modify the cache) and synchronize concurrent dentry caching attempts on a per
dentry basis. We still require to hold renameMu for writing while destroying
dentries and evicting from the cache but this still significantly reduces the
write locking critical section.
Local benchmarking showed that this improved runsc build benchmark time by 4-5%.
Across 6 runs, without this change it took 310.9025 seconds to build runsc
while with this change it took 296.127 seconds.
Runsc build benchmark's mutex profile: https://gvisor.dev/profile/gvisor-buildkite/78a3f968-36ca-4944-93f7-77a8792d56b4/28a1d260-790b-4a9e-94da-a4daede08ee3/tmp/profile/ptrace/BenchmarkBuildRunsc/page_cache.clean/filesystem.bindfs/benchmarks/runsc/mutex.pprof/flamegraph
PiperOrigin-RevId: 368958136
|
|
Add a coverage-report flag that will cause the sandbox to generate a coverage
report (with suffix .cov) in the debug log directory upon exiting. For the
report to be generated, runsc must have been built with the following Bazel
flags: `--collect_code_coverage --instrumentation_filter=...`.
With coverage reports, we should be able to aggregate results across all tests
to surface code coverage statistics for the project as a whole.
The report is simply a text file with each line representing a covered block
as `file:start_line.start_col,end_line.end_col`. Note that this is similar to
the format of coverage reports generated with `go test -coverprofile`,
although we omit the count and number of statements, which are not useful for
us.
Some simple ways of getting coverage reports:
bazel test <some_test> --collect_code_coverage \
--instrumentation_filter=//pkg/...
bazel build //runsc --collect_code_coverage \
--instrumentation_filter=//pkg/...
runsc -coverage-report=dir/ <other_flags> do ...
PiperOrigin-RevId: 368952911
|
|
Also count failed TCP port allocations
PiperOrigin-RevId: 368939619
|
|
Fields allow counter metrics to have multiple tabular values.
At most one field is supported at the moment.
PiperOrigin-RevId: 368767040
|
