| Age | Commit message (Collapse) | Author |
|---|
|
|
|
PiperOrigin-RevId: 323553832
|
|
|
|
PiperOrigin-RevId: 323508910
|
|
|
|
As it happens
gvisor/tools/bazel.mk:88
useradd --uid $(UID) --non-unique --no-create-home \
adds the user-id to /var/log/lastlog which happens to be a sparse file except
Go's tar support can't handle sparse files so it actually tries to allocate
the file to seek to the end causing the VM to run out of disk space.
See:
https://github.com/moby/moby/issues/5419#issuecomment-193876183
The fix is to pass -l to useradd to prevent it from trying to add to lastlog.
Fixes #3397
PiperOrigin-RevId: 323492591
|
|
|
|
PiperOrigin-RevId: 323491461
|
|
|
|
|
|
PiperOrigin-RevId: 323456118
|
|
PiperOrigin-RevId: 323455097
|
|
|
|
PiperOrigin-RevId: 323454998
|
|
|
|
The previous implementation of LinkAddressRequest only supported sending
broadcast ARP requests and multicast Neighbor Solicitations. The ability to
send these packets as unicast is required for Neighbor Unreachability
Detection.
Tests:
pkg/tcpip/network/arp:arp_test
- TestLinkAddressRequest
pkg/tcpip/network/ipv6:ipv6_test
- TestLinkAddressRequest
Updates #1889
Updates #1894
Updates #1895
Updates #1947
Updates #1948
Updates #1949
Updates #1950
PiperOrigin-RevId: 323451569
|
|
|
|
TCP now tracks the overhead of the segment structure itself in it's out-of-order
queue (pending). This is required to ensure that a malicious sender sending 1
byte out-of-order segments cannot queue like 1000's of segments which bloat up
memory usage.
We also reduce the default receive window to 32KB. With TCP moderation there is
no need to keep this window at 1MB which means that for new connections the
default out-of-order queue will be small unless the application actually reads
the data that is being sent. This prevents a sender from just maliciously
filling up pending buf with lots of tiny out-of-order segments.
PiperOrigin-RevId: 323450913
|
|
|
|
PiperOrigin-RevId: 323443142
|
|
|
|
This PR adds the following:
- [x] Marshall-able structs for fuse headers
- [x] Data structures needed in /dev/fuse to communicate with the daemon server
- [x] Implementation of the device interface
- [x] Go unit tests
This change adds the `/dev/fuse` implementation. `Connection` controls the
communication between the server and the sentry. The FUSE server uses
the `FileDescription` interface to interact with the Sentry. The Sentry
implmenetation of fusefs, uses `Connection` and the Connection interface
to interact with the Server. All communication messages are in the form
of `go_marshal` backed structs defined in the ABI package.
This change also adds some go unit tests that test (pretty basically)
the interfaces and should be used as an example of an end to end FUSE
operation.
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/3083 from ridwanmsharif:ridwanmsharif/fuse-device-impl 69aa2ce970004938fe9f918168dfe57636ab856e
PiperOrigin-RevId: 323428180
|
|
|
|
PiperOrigin-RevId: 323426851
|
|
|
|
PiperOrigin-RevId: 323426155
|
|
|
|
The subsequent systrap changes will need to import memmap from
the platform package.
PiperOrigin-RevId: 323409486
|
|
|
|
PiperOrigin-RevId: 323398518
|
|
|
|
The bazel server was being started as the wrong user, leading to issues
where the container would suddenly exit during a build.
We can also simplify the waiting logic by starting the container in two
separate steps: those that must complete first, then the asynchronous bit.
PiperOrigin-RevId: 323391161
|
|
|
|
PiperOrigin-RevId: 323383320
|
|
|
|
PiperOrigin-RevId: 323381964
|
|
|
|
Storing *testing.T on test helper structs is problematic when
subtests are used, because it is possible for nested tests to call
Fatal on parent test, which incorrect terminates the parent test.
For example
func TestOuter(t *testing.T) {
dut := NewDUT(t)
t.Run("first test", func(t *testing.T) {
dut.FallibleCall()
})
t.Run("second test", func(t *testing.T) {
dut.FallibleCall()
}
}
In the example above, assuming `FallibleCall` calls `t.Fatal` on the
`t` it holds, if `dut.FallibleCall` fails in "first test", it will
call `Fatal` on the parent `t`, quitting `TestOuter`. This is not a
behavior we want.
PiperOrigin-RevId: 323350241
|
|
|
|
Adds profiling with `runsc debug` or pprof to dockerutil. All
targets using dockerutil should now be able to use profiling.
In addition, modifies existing benchmarks to use profiling.
PiperOrigin-RevId: 323298634
|
|
|
|
Mark the currently passing integration/image tests for
VFS2. Bugs will be filed for remaining failing tests.
Updates #1487
PiperOrigin-RevId: 323297260
|
|
At present, when doing syscall_kvm test, we need to
enable the function of ESR_ELx_SYS64_ISS_SYS_CNTVCT/ESR_ELx_SYS64_ISS_SYS_CNTFRQ to
successfully pass the test.
I set CNTKCTL_EL1.EL0VCTEN==1/CNTKCTL_EL1.EL0PCTEN==1, so that the related cases can passed.
Signed-off-by: Bin Lu <bin.lu@arm.com>
|
|
|
|
... when it is possible.
The guitar gVisorKernel*Workflow-s runs test with the local execution_method.
In this case, blaze runs test cases locally without sandboxes. This means
that all tests run in the same network namespace. We have a few tests which
use hard-coded network ports and they can fail if one of these port will be
used by someone else or by another test cases.
PiperOrigin-RevId: 323137254
|
|
Using "--no-cache-dir" flag in pip install ,make sure dowloaded packages
by pip don't cached on system . This is a best practise which make sure
to fetch ftom repo instead of using local cached one . Further , in case
of Docker Containers , by restricing caching , we can reduce image size.
In term of stats , it depends upon the number of python packages
multiplied by their respective size . e.g for heavy packages with a lot
of dependencies it reduce a lot by don't caching pip packages.
Further , more detail information can be found at
https://medium.com/sciforce/strategies-of-docker-images-optimization-2ca9cc5719b6
|
|
|
|
The "dev" target had been failing. The failure was being caused due to variable
overload of "RUNTIME".
PiperOrigin-RevId: 323106040
|
|
|
|
The travis capacity is limited, but we build and test amd64 on kokoro.
PiperOrigin-RevId: 323103934
|
