| Age | Commit message (Collapse) | Author |
|---|
|
In the general case, files may have offsets between MaxInt64 and MaxUint64; in
Linux pgoff is consistently represented by an unsigned long, and in gVisor the
offset types in memmap.MappableRange are uint64. However, regular file mmap is
constrained to int64 offsets (on 64-bit systems) by
mm/mmap.c:file_mmap_size_max() => MAX_LFS_FILESIZE == LLONG_MAX.
As a related fix, check for chunkStart overflow in fsutil.HostFileMapper; chunk
offsets are uint64s, but as noted above some file types may use uint64 offsets
beyond MaxInt64.
Reported-by: syzbot+71342a1585aed97ed9f7@syzkaller.appspotmail.com
PiperOrigin-RevId: 397136751
|
|
Previously, this check always failed because we did not provide MAP_SHARED
or MAP_PRIVATE.
PiperOrigin-RevId: 390251086
|
|
For file-based mmap tests, the underlying file system may not support
mmaps depending on the sandbox configuration. This is case when
caching is disabled for goferfs.
PiperOrigin-RevId: 389052722
|
|
PiperOrigin-RevId: 354367665
|
|
PiperOrigin-RevId: 339504677
|
|
There is a new random issue on some Arm64 machines.
This scene can be summarized as following:
Sometimes, the content of the func() pointer is still 0 opcode.
The probability of this kind of issue is very low,
currently only available on some machines.
After inserting a simple memory barrier, this issue was gone.
The code to directly use the memory barrier is as follows:
memcpy(reinterpret_cast<void*>(addr), machine_code, sizeof(machine_code));
isb()
func = reinterpret_cast<uint32_t (*)(void)>(addr);
Signed-off-by: Bin Lu <bin.lu@arm.com>
|
|
Some systems return 128 + errno instead of just errno, which is the case
here.
PiperOrigin-RevId: 327247836
|
|
Signed-off-by: Haibo Xu <haibo.xu@arm.com>
Change-Id: I8008c0375fc7e23225a21026f359e78e691729e5
|
|
These were out-of-band notes that can help provide additional context
and simplify automated imports.
PiperOrigin-RevId: 293525915
|
|
PiperOrigin-RevId: 290846481
|
|
PiperOrigin-RevId: 290840370
|
|
This test suite has existed for quite a while and has become kind of messy.
Various tests can be joined together by parameterizing.
PiperOrigin-RevId: 286482240
|
|
PiperOrigin-RevId: 281795269
|
|
PiperOrigin-RevId: 255679603
|
|
Based on the guidelines at
https://opensource.google.com/docs/releasing/authors/.
1. $ rg -l "Google LLC" | xargs sed -i 's/Google LLC.*/The gVisor Authors./'
2. Manual fixup of "Google Inc" references.
3. Add AUTHORS file. Authors may request to be added to this file.
4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS.
Fixes #209
PiperOrigin-RevId: 245823212
Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
|
|
PiperOrigin-RevId: 245818639
Change-Id: I03703ef0fb9b6675955637b9fe2776204c545789
|
|
- Document fsutil.CachedFileObject.FD() requirements on access
permissions, and change gofer.inodeFileState.FD() to honor them.
Fixes #147.
- Combine gofer.inodeFileState.readonly and
gofer.inodeFileState.readthrough, and simplify handle caching logic.
- Inline gofer.cachePolicy.cacheHandles into
gofer.inodeFileState.setSharedHandles, because users with access to
gofer.inodeFileState don't necessarily have access to the fs.Inode
(predictably, this is a save/restore problem).
Before this CL:
$ docker run --runtime=runsc-d -v $(pwd)/gvisor/repro:/root/repro -it ubuntu bash
root@34d51017ed67:/# /root/repro/runsc-b147
mmap: 0x7f3c01e45000
Segmentation fault
After this CL:
$ docker run --runtime=runsc-d -v $(pwd)/gvisor/repro:/root/repro -it ubuntu bash
root@d3c3cb56bbf9:/# /root/repro/runsc-b147
mmap: 0x7f78987ec000
o
PiperOrigin-RevId: 240818413
Change-Id: I49e1d4a81a0cb9177832b0a9f31a10da722a896b
|
|
PiperOrigin-RevId: 224886231
Change-Id: I0fccb4d994601739d8b16b1d4e6b31f40297fb22
|
