summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/fs
AgeCommit message (Collapse)Author
2019-11-27Merge release-20191114.0-39-g20279c3 (automated)gVisor bot
2019-11-26Allow open(O_TRUNC) and (f)truncate for proc files.Ian Lewis
This allows writable proc and devices files to be opened with O_CREAT|O_TRUNC. This is encountered most frequently when interacting with proc or devices files via the command line. e.g. $ echo 8192 1048576 4194304 > /proc/sys/net/ipv4/tcp_rmem Also adds a test to test the behavior of open(O_TRUNC), truncate, and ftruncate on named pipes. Fixes #1116 PiperOrigin-RevId: 282677425
2019-11-25Merge release-20191114.0-30-g0416c24 (automated)gVisor bot
2019-11-25Merge pull request #1176 from xiaobo55x:runsc_bootgVisor bot
PiperOrigin-RevId: 282382564
2019-11-21Merge release-20191114.0-18-gc0f89eb (automated)gVisor bot
2019-11-21Import and structure cleanup.Adin Scannell
PiperOrigin-RevId: 281795269
2019-11-20Merge release-20191114.0-16-g012102e (automated)gVisor bot
2019-11-20Pass OpenTruncate to gofer in Open call when opening file with O_TRUNC.Nicolas Lacasse
Note that the Sentry still calls Truncate() on the file before calling Open. A new p9 version check was added to ensure that the p9 server can handle the the OpenTruncate flag. If not, then the flag is stripped before sending. PiperOrigin-RevId: 281609112
2019-11-18Merge release-20191114.0-13-g235a96c (automated)gVisor bot
2019-11-18Merge pull request #1177 from xiaobo55x:fs_hostgVisor bot
PiperOrigin-RevId: 281112758
2019-11-15Merge release-20191104.0-43-g339536d (automated)gVisor bot
2019-11-14Check that a file is a regular file with open(O_TRUNC).Kevin Krakauer
It was possible to panic the sentry by opening a cache revalidating folder with O_TRUNC|O_CREAT. Avoids breaking php tests. PiperOrigin-RevId: 280533213
2019-11-13Merge release-20191104.0-36-gc2d3dc0 (automated)gVisor bot
2019-11-12Use overlay MountSource when binding socket in overlay.Nicolas Lacasse
PiperOrigin-RevId: 280131840
2019-11-13Enable sentry/fs/host support on arm64.Haibo Xu
newfstatat() syscall is not supported on arm64, so we resort to use the fstatat() syscall. Signed-off-by: Haibo Xu <haibo.xu@arm.com> Change-Id: Iea95550ea53bcf85c01f7b3b95da70ad0952177d
2019-11-13Enable runsc/boot support on arm64.Haibo Xu
This patch also include a minor change to replace syscall.Dup2 with syscall.Dup3 which was missed in a previous commit(ref a25a976). Signed-off-by: Haibo Xu <haibo.xu@arm.com> Change-Id: I00beb9cc492e44c762ebaa3750201c63c1f7c2f3
2019-11-08Merge release-20190806.1-383-gaf58a4e (automated)gVisor bot
2019-11-08Automated rollback of changelist 278417533Kevin Krakauer
PiperOrigin-RevId: 279365629
2019-11-04Merge release-20190806.1-368-g4fdd69d (automated)gVisor bot
2019-11-04Check that a file is a regular file with open(O_TRUNC).Kevin Krakauer
It was possible to panic the sentry by opening a cache revalidating folder with O_TRUNC|O_CREAT. PiperOrigin-RevId: 278417533
2019-10-23Merge release-20190806.1-315-g6d4d956 (automated)gVisor bot
2019-10-23Merge pull request #641 from tanjianfeng:mastergVisor bot
PiperOrigin-RevId: 276380008
2019-10-16Reorder BUILD license and load functions in gvisor.Kevin Krakauer
PiperOrigin-RevId: 275139066
2019-10-16Merge release-20190806.1-281-g9fb5622 (automated)gVisor bot
2019-10-16Merge release-20190806.1-280-gfd4e436 (automated)gVisor bot
2019-10-16Fix problem with open FD when copy up is triggered in overlayfsFabricio Voznika
Linux kernel before 4.19 doesn't implement a feature that updates open FD after a file is open for write (and is copied to the upper layer). Already open FD will continue to read the old file content until they are reopened. This is especially problematic for gVisor because it caches open files. Flag was added to force readonly files to be reopenned when the same file is open for write. This is only needed if using kernels prior to 4.19. Closes #1006 It's difficult to really test this because we never run on tests on older kernels. I'm adding a test in GKE which uses kernels with the overlayfs problem for 1.14 and lower. PiperOrigin-RevId: 275115289
2019-10-16Support O_SYNC and O_DSYNC flags.Nicolas Lacasse
When any of these flags are set, all writes will trigger a subsequent fsync call. This behavior already existed for "write-through" mounts. O_DIRECT is treated as an alias for O_SYNC. Better support coming soon. PiperOrigin-RevId: 275114392
2019-10-16Merge release-20190806.1-278-gd22f053 (automated)gVisor bot
2019-10-16Merge pull request #736 from tanjianfeng:fix-unixgVisor bot
PiperOrigin-RevId: 275114157
2019-10-15support /proc/net/routeJianfeng Tan
This proc file reports routing information to applications inside the container. Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com> Change-Id: I498e47f8c4c185419befbb42d849d0b099ec71f3
2019-10-15support /proc/net/snmpJianfeng Tan
This proc file contains statistics according to [1]. [1] https://tools.ietf.org/html/rfc2013 Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com> Change-Id: I9662132085edd8a7783d356ce4237d7ac0800d94
2019-10-08Merge release-20190806.1-246-g1de0cf3 (automated)gVisor bot
2019-10-07Remove unnecessary context parameter for new pipes.Kevin Krakauer
PiperOrigin-RevId: 273421634
2019-10-05Merge release-20190806.1-239-gf24c318 (automated)gVisor bot
2019-10-04Add sanity check that overlayCreate is called with an overlay parent inode.Nicolas Lacasse
PiperOrigin-RevId: 272987037
2019-10-02Merge release-20190806.1-231-gcde7711 (automated)gVisor bot
2019-10-02Merge pull request #865 from tanjianfeng:fix-829gVisor bot
PiperOrigin-RevId: 272522508
2019-10-02Merge release-20190806.1-228-g2016cc2 (automated)gVisor bot
2019-10-02fs/proc: report PID-s from a pid namespace of the proc mountAndrei Vagin
Right now, we can find more than one process with the 1 PID in /proc. $ for i in `seq 10`; do > unshare -fp sleep 1000 & > done $ ls /proc 1 1 1 1 12 18 24 29 6 loadavg net sys version 1 1 1 1 16 20 26 32 cpuinfo meminfo self thread-self 1 1 1 1 17 21 28 36 filesystems mounts stat uptime PiperOrigin-RevId: 272506593
2019-10-01Merge release-20190806.1-221-gdd69b49 (automated)gVisor bot
2019-10-01Disable cpuClockTicker when app is idleMichael Pratt
Kernel.cpuClockTicker increments kernel.cpuClock, which tasks use as a clock to track their CPU usage. This improves latency in the syscall path by avoid expensive monotonic clock calls on every syscall entry/exit. However, this timer fires every 10ms. Thus, when all tasks are idle (i.e., blocked or stopped), this forces a sentry wakeup every 10ms, when we may otherwise be able to sleep until the next app-relevant event. These wakeups cause the sentry to utilize approximately 2% CPU when the application is otherwise idle. Updates to clock are not strictly necessary when the app is idle, as there are no readers of cpuClock. This commit reduces idle CPU by disabling the timer when tasks are completely idle, and computing its effects at the next wakeup. Rather than disabling the timer as soon as the app goes idle, we wait until the next tick, which provides a window for short sleeps to sleep and wakeup without doing the (relatively) expensive work of disabling and enabling the timer. PiperOrigin-RevId: 272265822
2019-10-01Merge release-20190806.1-216-g7a234f7 (automated)gVisor bot
2019-09-30splice: try another fallback option only if the previous one isn't supportedAndrei Vagin
Reported-by: syzbot+bb5ed342be51d39b0cbb@syzkaller.appspotmail.com PiperOrigin-RevId: 272110815
2019-09-30Merge release-20190806.1-210-g3ad17ff (automated)gVisor bot
2019-09-30Force timestamps to update when set via InodeOperations.SetTimestamps.Nicolas Lacasse
The gofer's CachingInodeOperations implementation contains an optimization for the common open-read-close pattern when we have a host FD. In this case, the host kernel will update the timestamp for us to a reasonably close time, so we don't need an extra RPC to the gofer. However, when the app explicitly sets the timestamps (via futimes or similar) then we actually DO need to update the timestamps, because the host kernel won't do it for us. To fix this, a new boolean `forceSetTimestamps` was added to CachineInodeOperations.SetMaskedAttributes. It is only set by gofer.InodeOperations.SetTimestamps. PiperOrigin-RevId: 272048146
2019-09-25Merge release-20190806.1-182-g99c86b8 (automated)gVisor bot
2019-09-24tty: fix sending SIGTTOU on tty writehenry.tjf
How to reproduce: $ echo "timeout 10 ls" > foo.sh $ chmod +x foo.sh $ ./foo.sh (will hang here for 10 secs, and the output of ls does not show) When "ls" process writes to stdout, it receives SIGTTOU signal, and hangs there. Until "timeout" process timeouts, and kills "ls" process. The expected result is: "ls" writes its output into tty, and terminates immdedately, then "timeout" process receives SIGCHLD and terminates. The reason for this failure is that we missed the check for TOSTOP (if set, background processes will receive the SIGTTOU signal when they do write). We use drivers/tty/n_tty.c:n_tty_write() as a reference. Fixes: #862 Reported-by: chris.zn <chris.zn@antfin.com> Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com> Signed-off-by: chenglang.hy <chenglang.hy@antfin.com>
2019-09-20Implement /proc/net/tcp6Jianfeng Tan
Fixes: #829 Signed-off-by: Jianfeng Tan <henry.tjf@antfin.com> Signed-off-by: Jielong Zhou <jielong.zjl@antfin.com>
2019-09-19Merge release-20190806.1-159-g0a8a75f (automated)gVisor bot
2019-09-19Job control: controlling TTYs and foreground process groups.Kevin Krakauer
Adresses a deadlock with the rolled back change: https://github.com/google/gvisor/commit/b6a5b950d28e0b474fdad160b88bc15314cf9259 Creating a session from an orphaned process group was causing a lock to be acquired twice by a single goroutine. This behavior is addressed, and a test (OrphanRegression) has been added to pty.cc. Implemented the following ioctls: - TIOCSCTTY - set controlling TTY - TIOCNOTTY - remove controlling tty, maybe signal some other processes - TIOCGPGRP - get foreground process group. Also enables tcgetpgrp(). - TIOCSPGRP - set foreground process group. Also enabled tcsetpgrp(). Next steps are to actually turn terminal-generated control characters (e.g. C^c) into signals to the proper process groups, and to send SIGTTOU and SIGTTIN when appropriate. PiperOrigin-RevId: 270088599
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 18:46:39 +0000