Age | Commit message (Collapse) | Author |
|
PiperOrigin-RevId: 355675900
|
|
Instead build the executable into the image.
PiperOrigin-RevId: 355631672
|
|
Our implementation of vfs.CheckDeleteSticky was not consistent with Linux,
specifically not consistent with fs/linux.h:check_sticky().
One of the biggest differences was that the vfs implementation did not
allow the owner of the sticky directory to delete files inside it that belonged
to other users.
This change makes our implementation consistent with Linux.
Also adds an integration test to check for this. This bug is also present in
VFS1.
Updates #3027
PiperOrigin-RevId: 355557425
|
|
This makes it easier to add more tests that run on Ubuntu. We can now just
add a bash script and call that from integration_test without having to set up
another image.
PiperOrigin-RevId: 355000410
|
|
Test failure happens when `echo` writes late:
* Server nc shuts down write when it sees EOF from stdin.
* Client nc closes the connection when it detects EOF from socket and no data
in internal write buffer.
Using `-q` flag to make server not shutting down write in the beginning, while
letting connection to be closed by client. As `-q` flag's default value varies
in different netcat versions, we always specify it to prevent future breakage.
PiperOrigin-RevId: 349504016
|
|
Closes #5048
PiperOrigin-RevId: 348050472
|
|
PiperOrigin-RevId: 346101076
|
|
Docker does not have IPv6 port forwarding as tracked by the following issue:
https://github.com/moby/moby/issues/11518
So when running bazel itself inside a docker container, we can not use the host
port bindings to communicate with sockets inside the container. This was causing
integration tests and image tests to fail when run through our Makefile targets.
PiperOrigin-RevId: 332355051
|
|
Mark all tests passing for VFS2 in:
image_test
integration_test
There's no way to do negative look ahead/behind in golang test regex,
so check if the tests uses VFS2 and skip CheckPointRestore if it does.
PiperOrigin-RevId: 326050915
|
|
Updates #1198
PiperOrigin-RevId: 325350818
|
|
9P2000.L is silent as to how readdir RPCs interact with directory mutation. The
most performant option is for Treaddir with offset=0 to restart iteration,
avoiding needing to walk+open+clunk a new directory fid between invocations of
getdents64(2), and the VFS2 gofer client assumes this is the case. Make this
actually true for the runsc fsgofer.
Fixes #3344, #3345, #3355
PiperOrigin-RevId: 324090384
|
|
PiperOrigin-RevId: 324080111
|
|
PiperOrigin-RevId: 322265513
|
|
Moves following to new dockerutil API:
- //test/e2e:integration_test
- //test/image:image_test
- //test/iptables:iptables_test
- //test/root:root_test
- //test/packetimpact:packetimpact_test
PiperOrigin-RevId: 320253118
|
|
This currently doesn't work with VSF2. Add test to ensure
it's not missed.
Updates #1487
PiperOrigin-RevId: 317013792
|
|
This change has multiple small components.
First, the chunk size is bumped to 1GB in order to avoid creating excessive
VMAs in the Sentry, which can lead to VMA exhaustion (and hitting limits).
Second, gap-tracking is added to the usage set in order to efficiently scan
for available regions.
Third, reclaim is moved to a simple segment set. This is done to allow the
order of reclaim to align with the Allocate order (which becomes much more
complex when trying to track a "max page" as opposed to "min page", so we
just track explicit segments instead, which should make reclaim scanning
faster anyways).
Finally, the findAvailable function attempts to scan from the top-down, in
order to maximize opportunities for VMA merging in applications (hopefully
preventing the same VMA exhaustion that can affect the Sentry).
PiperOrigin-RevId: 315009249
|
|
Split check for file in /tmp from working directory test.
Fix readonly case which should not fail to create working
dir.
PiperOrigin-RevId: 312702930
|
|
Linux 4.18 and later make reads and writes coherent between pre-copy-up and
post-copy-up FDs representing the same file on an overlay filesystem. However,
memory mappings remain incoherent:
- Documentation/filesystems/overlayfs.rst, "Non-standard behavior": "If a file
residing on a lower layer is opened for read-only and then memory mapped with
MAP_SHARED, then subsequent changes to the file are not reflected in the
memory mapping."
- fs/overlay/file.c:ovl_mmap() passes through to the underlying FD without any
management of coherence in the overlay.
- Experimentally on Linux 5.2:
```
$ cat mmap_cat_page.c
#include <err.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>
int main(int argc, char **argv) {
if (argc < 2) {
errx(1, "syntax: %s [FILE]", argv[0]);
}
const int fd = open(argv[1], O_RDONLY);
if (fd < 0) {
err(1, "open(%s)", argv[1]);
}
const size_t page_size = sysconf(_SC_PAGE_SIZE);
void* page = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, 0);
if (page == MAP_FAILED) {
err(1, "mmap");
}
for (;;) {
write(1, page, strnlen(page, page_size));
if (getc(stdin) == EOF) {
break;
}
}
return 0;
}
$ gcc -O2 -o mmap_cat_page mmap_cat_page.c
$ mkdir lowerdir upperdir workdir overlaydir
$ echo old > lowerdir/file
$ sudo mount -t overlay -o "lowerdir=lowerdir,upperdir=upperdir,workdir=workdir" none overlaydir
$ ./mmap_cat_page overlaydir/file
old
^Z
[1]+ Stopped ./mmap_cat_page overlaydir/file
$ echo new > overlaydir/file
$ cat overlaydir/file
new
$ fg
./mmap_cat_page overlaydir/file
old
```
Therefore, while the VFS1 gofer client's behavior of reopening read FDs is only
necessary pre-4.18, replacing existing memory mappings (in both sentry and
application address spaces) with mappings of the new FD is required regardless
of kernel version, and this latter behavior is common to both VFS1 and VFS2.
Re-document accordingly, and change the runsc flag to enabled by default.
New test:
- Before this CL: https://source.cloud.google.com/results/invocations/5b222d2c-e918-4bae-afc4-407f5bac509b
- After this CL: https://source.cloud.google.com/results/invocations/f28c747e-d89c-4d8c-a461-602b33e71aab
PiperOrigin-RevId: 311361267
|
|
This change adds a layer of abstraction around the internal Docker APIs,
and eliminates all direct dependencies on Dockerfiles in the infrastructure.
A subsequent change will automated the generation of local images (with
efficient caching). Note that this change drops the use of bazel container
rules, as that experiment does not seem to be viable.
PiperOrigin-RevId: 308095430
|
|
It's possible to execute the command that checks user's
$HOME dir before the user is created. Move the code that
creates the user inside exec so it can be serialized.
PiperOrigin-RevId: 302986184
|
|
PiperOrigin-RevId: 300171916
|
|
PiperOrigin-RevId: 291745021
|
|
PiperOrigin-RevId: 277189064
|
|
PiperOrigin-RevId: 275565958
|
|
Adds two tests. One to make sure that $HOME is set when starting a container
via 'docker run' and one to make sure that $HOME is set for each container in a
multi-container sandbox.
Issue #701
PiperOrigin-RevId: 273395763
|
|
'docker exec' was getting CAP_NET_RAW even when --net-raw=false
because it was not filtered out from when copying container's
capabilities.
PiperOrigin-RevId: 272260451
|
|
We already do this for `runsc run`, but need to do the same for `runsc exec`.
PiperOrigin-RevId: 270793459
|
|
PiperOrigin-RevId: 270764996
|
|
The simple test script has gotten out of control. Shard this script into
different pieces and attempt to impose order on overall test structure. This
change helps lay some of the foundations for future improvements.
* The runsc/test directories are moved into just test/.
* The runsc/test/testutil package is split into logical pieces.
* The scripts/ directory contains new top-level targets.
* Each test is now responsible for building targets it requires.
* The install functionality is moved into `runsc` itself for simplicity.
* The existing kokoro run_tests.sh file now just calls all (can be split).
After this change is merged, I will create multiple distinct workflows for
Kokoro, one for each of the scripts currently targeted by `run_tests.sh` today,
which should dramatically reduce the time-to-run for the Kokoro tests, and
provides a better foundation for further improvements to the infrastructure.
PiperOrigin-RevId: 267081397
|