While there is a difference between flavors of this ioctl (`TCSETS`,
`TCSETSF`, `TCSETSW`), in practice it seems not to matter. We should let
users call `TCSETSF` and can implement those differences if necessary.
Fixes two issues in TTOU handling while handling TIOCSPGRP on a tty
device.
fixes#7941; see that issue for details of the bugs.
Updates the tests to test the fixed behavior; both tests are verified
to fail without the `thread_group.go` fixes.
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from PtyTest
[ RUN ] PtyTest.TermiosICANONEOF
test/syscalls/linux/pty.cc:464: Failure
Value of: ReadFd(fd.get(), &c, 1)
Expected: -1 (failure), with errno PosixError(errno=11 Resource temporarily unavailable)
Actual: 0 (of type long)
[ FAILED ] PtyTest.TermiosICANONEOF (20018 ms)
[----------] 1 test from PtyTest (20018 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (20018 ms total)
[ PASSED ] 0 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] PtyTest.TermiosICANONEOF
PiperOrigin-RevId: 452799870
The test Truncate set ControllingTTY without releasing
it on VFS2. This leads test ReleaseTTYSignals and ReleaseTTY
fail when setting ControllingTTY.
Skip the test on VFS1 and native, as setting Controlling TTY
when open replica only happens on VFS2.
Signed-off-by: Howard Zhang <[email protected]>
ioctl calls with TIOCSCTTY fail if the calling process already has a
controlling terminal, which occurs on a 5.4 kernel like our Ubuntu 18 CI.
Thus, run tests calling ioctl TTOCSCTTY in clean subprocess.
Also, while we're here, switch out non-inclusive master/slave for main/replica.
PiperOrigin-RevId: 328756598
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
Adresses a deadlock with the rolled back change:
https://github.com/google/gvisor/commit/e72cf7af1fcbef3d9fb9bf102435bb36dd302a63
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
(Don't worry, this is mostly tests.)
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: 261387276
bazel has a lot of dependencies and users don't want to install them
just to build gvisor.
These changes allows to run bazel in a docker container.
A bazel cache is on the local file system (~/.cache/bazel), so
incremental builds should be fast event after recreating a bazel
container.
Here is an example how to build runsc:
make BAZEL_OPTIONS="build runsc:runsc" bazel
Change-Id: I8c0a6d0c30e835892377fb6dd5f4af7a0052d12a
PiperOrigin-RevId: 246570877
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
The previous implementation revolved around runes instead of bytes, which caused
weird behavior when converting between the two. For example, peekRune would read
the byte 0xff from a buffer, convert it to a rune, then return it. As rune is an
alias of int32, 0xff was 0-padded to int32(255), which is the hex code point for
?. However, peekRune also returned the length of the byte (1). When calling
utf8.EncodeRune, we only allocated 1 byte, but tried the write the 2-byte
character ?.
tl;dr: I apparently didn't understand runes when I wrote this.
PiperOrigin-RevId: 241789081
Change-Id: I14c788af4d9754973137801500ef6af7ab8a8727
Kevin Krakauer