Age | Commit message (Collapse) | Author |
|
`runsc ps` currently return pid for a task's immediate pid namespace,
which is confusing when there're multiple pid namespaces. We should
return only pids in the root namespace.
Before:
```
1000 1 0 0 ? 02:24 250ms chrome
1000 1 0 0 ? 02:24 40ms dumb-init
1000 1 0 0 ? 02:24 240ms chrome
1000 2 1 0 ? 02:24 2.78s node
```
After:
```
UID PID PPID C TTY STIME TIME CMD
1000 1 0 0 ? 12:35 0s dumb-init
1000 2 1 7 ? 12:35 240ms node
1000 13 2 21 ? 12:35 2.33s chrome
1000 27 13 3 ? 12:35 260ms chrome
```
Signed-off-by: Daniel Dao <dqminh@cloudflare.com>
|
|
Only detect and mitigate on mds for the mitigate command.
PiperOrigin-RevId: 358924466
|
|
Updates #3481
Closes #5430
PiperOrigin-RevId: 358923208
|
|
PiperOrigin-RevId: 358890980
|
|
Reported-by: syzbot+f2489ba0b999a45d1ad1@syzkaller.appspotmail.com
PiperOrigin-RevId: 358866218
|
|
Previously, loader.signalProcess was inconsitently using both root and
container's PID namespace to find the process. It used root namespace
for the exec'd process and container's PID namespace for other processes.
This fixes the code to use the root PID namespace across the board, which
is the same PID reported in `runsc ps` (or soon will after
https://github.com/google/gvisor/pull/5519).
PiperOrigin-RevId: 358836297
|
|
This removes a three-lock deadlock between fdnotifier.notifier.mu,
epoll.EventPoll.listsMu, and baseEndpoint.mu.
A lock order comment was added to epoll/epoll.go.
Also fix unsafe access of baseEndpoint.connected/receiver.
PiperOrigin-RevId: 358515191
|
|
fio should scale by written/read bytes and not iterate runs
of the fio container.
PiperOrigin-RevId: 358511771
|
|
PiperOrigin-RevId: 358445320
|
|
PiperOrigin-RevId: 358354414
|
|
Also skips a test if the setsockopt to increase send buffer did not result in an
increase. This is possible when the underlying socket is a host backed unix
domain socket as in such cases gVisor does not permit increasing SO_SNDBUF.
PiperOrigin-RevId: 358285158
|
|
These are bumped to allow early testing of Go 1.17. Use will be audited closer
to the 1.17 release.
PiperOrigin-RevId: 358278615
|
|
Currently, iperf runs a client that scales by
bytes sent. In practice, this causes b.N to scale
slowly and have several short lived containers.
Instead, scale by KB to more quickly reach required time.
PiperOrigin-RevId: 358244926
|
|
This change also adds support for Router Alert option processing on
incoming packets, a new stat for Router Alert option, and exports
all the IP-option related stats.
Fixes #5491
PiperOrigin-RevId: 358238123
|
|
Remove unused argument while I'm here and avoid returning
syscall.Errno(0) which should rather be a nil error.
PiperOrigin-RevId: 358227396
|
|
Completes the soft migration to Unreachable state by removing the Failed state
and the the FailedEntryLookups StatCounter.
Fixes #4667
PiperOrigin-RevId: 358226380
|
|
Individual test cases must not rely on being executed in a clean environment.
PiperOrigin-RevId: 358207468
|
|
Previously, we make two connect attempts. If the first attempt is still on
going when the second attempt is made, the test will fail. This change deflakes
the situation by not making the second attempt, instead, we poll for the first
attempt's completion and read the errno from SO_ERROR.
PiperOrigin-RevId: 358104769
|
|
PiperOrigin-RevId: 358085809
|
|
PiperOrigin-RevId: 358078157
|
|
See https://github.com/golang/go/issues/19367 for rationale. Note that the
upstream decision arrived at in that thread, while useful for some of our use
cases, doesn't account for all of our SliceHeader use cases (we often use
SliceHeader to extract pointers from slices in a way that avoids bounds
checking and/or handles nil slices correctly) and also doesn't exist yet.
PiperOrigin-RevId: 358071574
|
|
Note that this CL reorders overlayEntry.copyMu before overlayEntry.dirCacheMu
in the overlayFileOperations.IterateDir() => readdirEntries() path - but this
lock ordering is already required by overlayRemove/Bind() =>
overlayEntry.markDirectoryDirty(), so this actually just fixes an
inconsistency.
PiperOrigin-RevId: 358047121
|
|
- TCP_INFO is used to get the RTO instead of calculating it manually.
PiperOrigin-RevId: 358032487
|
|
- Wrap comments at 80 columns
- Avoid duplicating the number of retries (5)
- Reduce indentation
- Use (*testing.T).Fatal rather than (*testing.T).Fatalf
PiperOrigin-RevId: 358017412
|
|
tcpip integration tests have been flaky lately. They usually run in 20 seconds
and have a 60 seconds timeout. Sometimes they timeout which could be due to
a bug or deadlock. To further investigate it might be helpful to split the
targets and see which test is causing the flake.
Added a new tcpip/tests/utils package to hold all common utilities across all
tests.
PiperOrigin-RevId: 358012936
|
|
We were opening dual-stack sockets, but tests only set iptables rules for a
single network protocol. Thus, packets (probably sent by previous tests) could
sneak in and break tests.
Tested with:
bazel test ///test/iptables:iptables_test
--test_arg=--runtime=runsc --nocache_test_results --test_output=errors
--runs_per_test=1000 --test_filter=TestFilterInputDropUDP
PiperOrigin-RevId: 357972385
|
|
Operations are now shut down automatically by the main Stop
command, and it is not necessary to call Stop during Destroy.
Fixes #5454
PiperOrigin-RevId: 357295930
|
|
Remove flaky tcp_reordering_test as it does not check reordering. We have
added new reorder tests in tcp_rack_test.go
PiperOrigin-RevId: 357278769
|
|
Rename operation params in iperf and tensorflow to
match other similar benchmarks.
PiperOrigin-RevId: 357250304
|
|
PiperOrigin-RevId: 357241880
|
|
Fix issue with iperf where b.N wasn't changing across runs.
Also, if the given runtime is runc/not given, don't run a profile against it.
PiperOrigin-RevId: 357231450
|
|
PiperOrigin-RevId: 357224877
|
|
This change implements TLP details enumerated in
https://tools.ietf.org/html/draft-ietf-tcpm-rack-08#section-7.5.3
Fixes #5085
PiperOrigin-RevId: 357125037
|
|
PiperOrigin-RevId: 357106080
|
|
Entry check:
- Earlier implementation was preventing us from entering recovery even if
SND.UNA is lost but dupAckCount is still below threshold. Fixed that.
- We should only enter recovery when at least one more byte of data beyond the
highest byte that was outstanding when fast retransmit was last entered is
acked. Added that check.
Exit check:
- Earlier we were checking if SEG.ACK is in range [SND.UNA, SND.NXT]. The
intention was to check if any unacknowledged data was ACKed. Note that
(SEG.ACK - 1) is actually the sequence number which was ACKed. So we were
incorrectly including (SND.UNA - 1) in the range. Fixed the check to now be
(SEG.ACK - 1) in range [SND.UNA, SND.NXT).
Additionally, moved a RACK specific test to the rack tests file.
Added tests for the changes I made.
PiperOrigin-RevId: 357091322
|
|
PiperOrigin-RevId: 357090170
|
|
Added a LINT IfChange/ThenChange check to catch this in the future.
PiperOrigin-RevId: 357077564
|
|
Implementing interfaces on value types causes the interface to be
implemented by both the value type and the pointer type of the
implementer. This complicates type assertion as it requires the
assertion to check for both the pointer type and the value type.
PiperOrigin-RevId: 357061063
|
|
PiperOrigin-RevId: 357031904
|
|
PiperOrigin-RevId: 357015186
|
|
rt_sigaction may be called by Go runtime when trying to panic:
https://cs.opensource.google/go/go/+/master:src/runtime/signal_unix.go;drc=ed3e4afa12d655a0c5606bcf3dd4e1cdadcb1476;bpv=1;bpt=1;l=780?q=rt_sigaction&ss=go
Updates #5038
PiperOrigin-RevId: 357013186
|
|
PiperOrigin-RevId: 356868412
|
|
TestRACKWithDuplicateACK is flaky as the reorder window can expire before
receiving three duplicate ACKs which will result in sending the first
unacknowledged segment twice: when reorder timer expired and again after
receiving the third duplicate ACK.
This CL will fix this behavior and will not resend the segment again if it was
already re-transmittted when reorder timer expired.
Update the TestRACKWithDuplicateACK to test that the first segment is
considered as lost and is re-transmitted.
PiperOrigin-RevId: 356855168
|
|
Linux does the same thing.
Reported-by: syzbot+6c79385c930c929d1d9e@syzkaller.appspotmail.com
PiperOrigin-RevId: 356854562
|
|
PiperOrigin-RevId: 356852625
|
|
PiperOrigin-RevId: 356843249
|
|
Deflake this test by retransmitting the ACK and retrying RST
expectation after the supposed state transition to CLOSED.
This gives time for the state transition to complete.
Without such a retransmit from the test, the ACK could get silently
dropped by the listener when the passively connecting endpoint
has not yet completely updated the state (in gVisor this would be
endpoint state and decrement of synRcvdCount).
PiperOrigin-RevId: 356825562
|
|
PiperOrigin-RevId: 356807933
|
|
PiperOrigin-RevId: 356784956
|
|
PiperOrigin-RevId: 356772367
|