Age | Commit message (Collapse) | Author | |
---|---|---|---|
2019-07-15 | Merge ab44d145 (automated) | gVisor bot | |
2019-07-12 | Merge c8ae00eb (automated) | gVisor bot | |
2019-07-12 | Merge 4ad67050 (automated) | gVisor bot | |
2019-07-12 | Merge eff2c264 (automated) | gVisor bot | |
2019-07-12 | Merge 69e0affa (automated) | gVisor bot | |
2019-07-09 | build: add nogo for static validation | Adin Scannell | |
PiperOrigin-RevId: 257297820 | |||
2019-07-03 | futex: compare keys for equality when doing a FUTEX_UNLOCK_PI. | Neel Natu | |
PiperOrigin-RevId: 256453827 | |||
2019-07-03 | Merge pull request #493 from ahmetb:reticulating-splines | gVisor bot | |
PiperOrigin-RevId: 256319059 | |||
2019-07-02 | Remove map from fd_map, change to fd_table. | Adin Scannell | |
This renames FDMap to FDTable and drops the kernel.FD type, which had an entire package to itself and didn't serve much use (it was freely cast between types, and served as more of an annoyance than providing any protection.) Based on BenchmarkFDLookupAndDecRef-12, we can expect 5-10 ns per lookup operation, and 10-15 ns per concurrent lookup operation of savings. This also fixes two tangential usage issues with the FDMap. Namely, non-atomic use of NewFDFrom and associated calls to Remove (that are both racy and fail to drop the reference on the underlying file.) PiperOrigin-RevId: 256285890 | |||
2019-07-02 | sentry/kernel: add syslog message | Ahmet Alp Balkan | |
It feels like "reticulating splines" is missing from the list of meaningless syslog messages. Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com> | |||
2019-06-28 | Add finalizer on AtomicRefCount to check for leaks. | Ian Gudger | |
PiperOrigin-RevId: 255711454 | |||
2019-06-28 | Merge b2907595 (automated) | gVisor bot | |
2019-06-27 | Complete pipe support on overlayfs | Fabricio Voznika | |
Get/Set pipe size and ioctl support were missing from overlayfs. It required moving the pipe.Sizer interface to fs so that overlay could get access. Fixes #318 PiperOrigin-RevId: 255511125 | |||
2019-06-27 | Merge 5b41ba5d (automated) | gVisor bot | |
2019-06-27 | Merge 085a9075 (automated) | gVisor bot | |
2019-06-27 | Fix various spelling issues in the documentation | Michael Pratt | |
Addresses obvious typos, in the documentation only. COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/443 from Pixep:fix/documentation-spelling 4d0688164eafaf0b3010e5f4824b35d1e7176d65 PiperOrigin-RevId: 255477779 | |||
2019-06-26 | Merge 857e5c47 (automated) | gVisor bot | |
2019-06-26 | Merge 67e2f227 (automated) | gVisor bot | |
2019-06-26 | Merge e98ce4a2 (automated) | gVisor bot | |
2019-06-25 | Merge 03ae91c6 (automated) | gVisor bot | |
2019-06-25 | gvisor: lockless read access for task credentials | Andrei Vagin | |
Credentials are immutable and even before these changes we could read them without locks, but we needed to take a task lock to get a credential object from a task object. It is possible to avoid this lock, if we will guarantee that a credential object will not be changed after setting it on a task. PiperOrigin-RevId: 254989492 | |||
2019-06-25 | Merge fd16a329 (automated) | gVisor bot | |
2019-06-22 | Merge 35719d52 (automated) | gVisor bot | |
2019-06-22 | Implement statx. | Nicolas Lacasse | |
We don't have the plumbing for btime yet, so that field is left off. The returned mask indicates that btime is absent. Fixes #343 PiperOrigin-RevId: 254575752 | |||
2019-06-22 | Merge ab6774ce (automated) | gVisor bot | |
2019-06-21 | Merge 6f933a93 (automated) | gVisor bot | |
2019-06-21 | Merge ae4ef32b (automated) | gVisor bot | |
2019-06-21 | Merge 72737532 (automated) | gVisor bot | |
2019-06-21 | Merge 5ba16d51 (automated) | gVisor bot | |
2019-06-21 | Merge c0317b28 (automated) | gVisor bot | |
2019-06-21 | Merge f94653b3 (automated) | gVisor bot | |
2019-06-21 | kernel: call t.mu.Unlock() explicitly in WithMuLocked | Andrei Vagin | |
defer here doesn't improve readability, but we know it slower that the explicit call. PiperOrigin-RevId: 254441473 | |||
2019-06-21 | Merge 335fd987 (automated) | gVisor bot | |
2019-06-21 | Merge 054b5632 (automated) | gVisor bot | |
2019-06-21 | Update comment | Fabricio Voznika | |
PiperOrigin-RevId: 254428866 | |||
2019-06-21 | Merge dc36c34a (automated) | gVisor bot | |
2019-06-20 | Merge 3c7448ab (automated) | gVisor bot | |
2019-06-20 | Merge 292f70cb (automated) | gVisor bot | |
2019-06-20 | Merge 0b213507 (automated) | gVisor bot | |
2019-06-20 | Merge 7e495156 (automated) | gVisor bot | |
2019-06-20 | Merge c2d87d5d (automated) | gVisor bot | |
2019-06-19 | Merge 773423a9 (automated) | gVisor bot | |
2019-06-19 | Merge 9d2efaac (automated) | gVisor bot | |
2019-06-19 | Merge f7428af9 (automated) | gVisor bot | |
2019-06-19 | Add MountNamespace to task. | Nicolas Lacasse | |
This allows tasks to have distinct mount namespace, instead of all sharing the kernel's root mount namespace. Currently, the only way for a task to get a different mount namespace than the kernel's root is by explicitly setting a different MountNamespace in CreateProcessArgs, and nothing does this (yet). In a follow-up CL, we will set CreateProcessArgs.MountNamespace when creating a new container inside runsc. Note that "MountNamespace" is a poor term for this thing. It's more like a distinct VFS tree. When we get around to adding real mount namespaces, this will need a better naem. PiperOrigin-RevId: 254009310 | |||
2019-06-19 | Merge ca245a42 (automated) | gVisor bot | |
2019-06-18 | Merge 546b2948 (automated) | gVisor bot | |
2019-06-18 | Merge 0e07c94d (automated) | gVisor bot | |
2019-06-18 | Merge bdb19b82 (automated) | gVisor bot | |
2019-06-18 | Merge ec15fb11 (automated) | gVisor bot | |