| Age | Commit message (Collapse) | Author |
|---|
|
PiperOrigin-RevId: 374464969
|
|
PiperOrigin-RevId: 374331016
|
|
PiperOrigin-RevId: 374319456
|
|
PiperOrigin-RevId: 374295866
|
|
|
|
This test suffers from extreme contention on
tcpip/stack.AddressableEndpointState.mu via
AddressableEndpointState.decAddressRef, at least when Go race detection is
enabled.
PiperOrigin-RevId: 374273745
|
|
cgroups in K8s are setup with the following hierarchy: `.../pod/container`.
The sandbox is created with the first container and consequently uses the
the pause container cgroup. This change removes the container cgroup from
the path to make the sandbox use the pod cgroup instead. Otherwise limits
set to the pause container will apply to the entire sandbox.
PiperOrigin-RevId: 374273277
|
|
Previously, we named domain objects using numbers (e.g. "e1", "e2" etc). This
change renames objects to clarify whether they are part of the incoming or
outgoing path.
PiperOrigin-RevId: 374226859
|
|
Weirdness metric will replace the below two metrics:
- watchdog/stuck_startup_detected
- watchdog/stuck_tasks_detected
PiperOrigin-RevId: 373895696
|
|
Make sure that the initial configurations used by the DAD state is
valid.
Before this change, an invalid DAD configuration (with a zero-valued
retransmit timer) was used so the DAD state would attempt to resolve
DAD immediately.
This lead to a deadlock in TestDADResolve as when DAD resolves, the
stack notifies the NDP dispatcher which would attempt to write to an
unbuffered channel while holding a lock. The test goroutine also
attempts to obtain a stack.Route (before receiving from the channel)
which ends up attempting to take the same lock.
Test: stack_test.TestDADResolve
PiperOrigin-RevId: 373888540
|
|
...instead of per NetworkProtocol to better conform with linux
(https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt):
```
conf/interface/*
forwarding - BOOLEAN
Enable IP forwarding on this interface. This controls whether packets
received _on_ this interface can be forwarded.
```
Fixes #5932.
PiperOrigin-RevId: 373888000
|
|
The new metric contains fields and will replace the below existing metric:
- opened_write_execute_file
PiperOrigin-RevId: 373884604
|
|
PiperOrigin-RevId: 373875071
|
|
O_PATH is now implemented in vfs2.
Fixes #2782.
PiperOrigin-RevId: 373861410
|
|
PiperOrigin-RevId: 373854462
|
|
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
|
|
PiperOrigin-RevId: 373846881
|
|
headerOffset() is incorrectly taking account of previous push(), so it thinks
there is more data to consume. This change switches to use pk.reserved as
pivot point.
Reported-by: syzbot+64fef9acd509976f9ce7@syzkaller.appspotmail.com
PiperOrigin-RevId: 373846283
|
|
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
|
|
This change updates the forwarding path to perform the forwarding hook
with iptables so that the filter table is consulted before a packet is
forwarded
Updates #170.
Test: iptables_test.TestForwardingHook
PiperOrigin-RevId: 373702359
|
|
When recovering from a zero-receive-window situation, and asked to
send out an ACK, ensure that we apply SWS avoidance in our window
updates.
Fixes #5984
PiperOrigin-RevId: 373689578
|
|
PiperOrigin-RevId: 373661350
|
|
cgroup controllers can be grouped together (e.g. cpu,cpuacct) and
that was confusing Cgroup.Install() into thinking that a cgroup
directory was created by the caller, when it had being created by
another controller that is grouped together.
PiperOrigin-RevId: 373661336
|
|
Benchmark iperf3:
Before After
native->runsc 5.14 5.01 (Gbps)
runsc->native 4.15 4.07 (Gbps)
It did introduce overhead, mainly at the bridge between pkg/buffer and
VectorisedView, the ExtractVV method. Once endpoints start migrating away from
VV, this overhead will be gone.
Updates #2404
PiperOrigin-RevId: 373651666
|
|
...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
|
|
We need to make sure that all children are closed before
return. But the last child saved in parent isn't closed
after we successfully iterate all the files in "names".
This patch fixes this issue.
Fixes #5982
Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
|
|
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: 373466994
|
|
This code path is for outgoing packets, and we don't currently do memory
accounting on this path. So it wasn't breaking anything.
This change did not add a test for ref-counting issue fixed, but will switch to
the leak-checking ref-counter later when all ref-counting issues are fixed.
PiperOrigin-RevId: 373447913
|
|
PiperOrigin-RevId: 373437576
|
|
PiperOrigin-RevId: 373417636
|
|
|
|
N.B. we don't explicitly support MIPS, but there's no reason it
shouldn't work.
|
|
PiperOrigin-RevId: 373271579
|
|
PiperOrigin-RevId: 373265454
|
|
PiperOrigin-RevId: 373221316
|
|
This is a hot path for all incoming packets and we don't
need an exclusive lock here as we are not modifying any
of the fields protected by mu here.
PiperOrigin-RevId: 373181254
|
|
This is in preparation of having aggregated NIC stats at the stack
level. These validation functions will be needed outside of the
network layer packages to test aggregated NIC stats.
PiperOrigin-RevId: 373180565
|
|
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
|
|
Fixes invocation of the Github issue reviver by including the required 'path'
command line option. Also updates the issue reviver to add a 'revived' label to
revived issues. Issues with a 'revived' label will no longer be marked as
stale.
PiperOrigin-RevId: 373046772
|
|
PiperOrigin-RevId: 372993341
|
|
|
|
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
|
|
|
|
|
|
|
|
|
