Proto commits in google/gvisor

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-07-07

Add seccheck field to indicate if executed binary is on overlayfs upper layer. This change introduces a new field `binary_overlayfs_upper` to the `ExecveBinaryInfo` seccheck point. This field is set to true if the executable being run is located on the upper layer of an overlay filesystem. A new helper function `overlay.IsCopiedUp` is added to check this condition. PiperOrigin-RevId: 913758999

Add seccheck point for mmap. This change introduces a new seccheck point, "sentry/mmap", which is triggered when a memory mapping is created. The seccheck event includes information about the mapped file, such as its path, inode, mode, UID, and GID, as well as a timestamp. It also indicates if the mapping corresponds to the initial executable. This allows for monitoring of potential code injection or execution from unexpected sources. PiperOrigin-RevId: 915566174

2026-07-06

Add checkpoint/restore coordination with libtpu to runsc. PiperOrigin-RevId: 943469548

The documentation is generated from this commit.

Add seccheck field to indicate if executed binary is on overlayfs upper layer. This change introduces a new field `binary_overlayfs_upper` to the `ExecveBinaryInfo` seccheck point. This field is set to true if the executable being run is located on the upper layer of an overlay filesystem. A new helper function `overlay.IsCopiedUp` is added to check this condition. PiperOrigin-RevId: 913758999

Add seccheck point for mmap. This change introduces a new seccheck point, "sentry/mmap", which is triggered when a memory mapping is created. The seccheck event includes information about the mapped file, such as its path, inode, mode, UID, and GID, as well as a timestamp. It also indicates if the mapping corresponds to the initial executable. This allows for monitoring of potential code injection or execution from unexpected sources. PiperOrigin-RevId: 915566174

Add seccheck field to indicate if executed binary is on overlayfs upper layer. This change introduces a new field `binary_overlayfs_upper` to the `ExecveBinaryInfo` seccheck point. This field is set to true if the executable being run is located on the upper layer of an overlay filesystem. A new helper function `overlay.IsCopiedUp` is added to check this condition. PiperOrigin-RevId: 913758999

2026-06-26

Implement save/restore for TPU/VFIO devices to enable cross device C/R. This change enables save and restore for TPU/VFIO such that they can be saved on one device and restored on another. The change tracks open VFIO/TPU FDs and, during save, captures the PCI Bus:Device:Function (BDF) and IOMMU group numbers so they can be properly remapped. During restore, it remaps these old IDs to new IDs based on the restored container's device configuration and reopens the necessary host file descriptors. The remapping information is passed via the context to the afterLoad methods of the VFIO/TPU FD implementations. PiperOrigin-RevId: 938132005

Add checkpoint/restore coordination with libtpu to runsc. PiperOrigin-RevId: 922310675

2026-06-05

Internal change. PiperOrigin-RevId: 927384056

Internal change. PiperOrigin-RevId: 927390410

Internal change. PiperOrigin-RevId: 927399029

Internal change. PiperOrigin-RevId: 927390251

Internal change. PiperOrigin-RevId: 927389828

Internal change. PiperOrigin-RevId: 927390359

2026-05-22

Add PPID to ContextData in gvisor seccheck PiperOrigin-RevId: 919895409

Internal change PiperOrigin-RevId: 919856743

2026-05-12

Add support for customizing the default nodepool in GKE tester. PiperOrigin-RevId: 914077000

Internal change PiperOrigin-RevId: 913914238

Internal change PiperOrigin-RevId: 913914237

Internal change PiperOrigin-RevId: 913914232

Internal change PiperOrigin-RevId: 913914231

2026-05-04

Internal change. PiperOrigin-RevId: 910311877

2026-04-29

Internal change. PiperOrigin-RevId: 907764703

2026-03-03

Fix new sandbox_options proto build. PiperOrigin-RevId: 878013302

Create initial sandbox configuration spec. This configuration will serve as the base for various language-specific sandbox APIs. PiperOrigin-RevId: 877625759

2026-02-27

Fix cos_gpu_compatibility_test Update the proto for the cos_gpu_compatibility_test so that it passes PiperOrigin-RevId: 876426910

2025-12-04

Remove pkg/shim/v1/runtimeoptions/v14 that supports containerd before v1.4. gVisor now supports containerd 1.6 and later. PiperOrigin-RevId: 840429781

2025-06-02

Kubernetes testcluster: Add "restore" nodepool. This is a nodepool configured identically to the test nodepool, and is meant to be a restore target for checkpoint/restore benchmarks. PiperOrigin-RevId: 766345186

2025-05-21

Internal change. PiperOrigin-RevId: 761600409

2025-02-25

Merge pull request #11473 from Champ-Goblem:shim-add-cgroup-v2-metrics-support PiperOrigin-RevId: 730560110

2025-02-24

netstack/packet: use lockdep mutexes FUTURE_COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/11473 from Champ-Goblem:shim-add-cgroup-v2-metrics-support b602afb7647546148cab820775aba3b57e767213 PiperOrigin-RevId: 730536578

2025-02-22

Relocate containerd-shim-runsc-v1 deps from shim/ to shim/v1. FUTURE_COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/11473 from Champ-Goblem:shim-add-cgroup-v2-metrics-support b602afb7647546148cab820775aba3b57e767213 PiperOrigin-RevId: 729612115

2025-01-30

Fix a few typos

2024-12-30

Kubernetes benchmarks: Refactor kubectl context to allow sets of clusters. Also add sanity check to make sure each cluster works as part of initialization, by running a sample pod within. PiperOrigin-RevId: 710786751

2024-12-23

Internal change (diffbased). PiperOrigin-RevId: 709157384

2024-11-06

Add test to check COS drivers as they are posted. Our current check of COS drivers often lags behind COS releases. This is due to needing to preload GPU docker images onto the images that run in our CI pipelines. In addition, COS can be a bit more complex than originally thought releasing driver versions both across GPU types and release branches. Thus, this test searches the latest COS images on each family for new drivers. It does this by looking at COS's published release notes which include a proto of LATEST/DEFAULT drivers selected for each device. This will flag new versions faster with more coverage than our CI pipeline currently. Due to this not actually needing a GPU to run, this can run on any VM. PiperOrigin-RevId: 693736100

2024-10-22

Unbreak build failures in Kubernetes benchmarks. This updates the Google Cloud APIs and their Go libraries to their latest versions, which adds some of the missing fields of the container cluster service v1 proto that didn't exist in the version defined in `WORKSPACE`. This also severs the proto import dependency of `test_range_config.proto` on the container cluster API proto, both because it shouldn't be GKE-specific but also because the Go genproto version of the container cluster API is different (from the Go linker's perspective) from the container cluster proto that is imported from `test_range_config.proto`. Instead, it is encoded as an "any" proto for both nodepools and clusters. Go repositories are re-arranged such that the genproto version imported is taken from the `WORKSPACE` file rather than the one embedded in other Go repositories earlier in the file. The version of this API in Go's genproto library is still missing some of the TPU node placement fields, so that part is filled in via reflection when available. That is hacky but that codepath only applies to TPU clusters so not applicable for most benchmarks. PiperOrigin-RevId: 688682505

2024-10-16

Add Kubernetes benchmarks suite. This is a large set of Kubernetes-based performance benchmarks that has been in use at Google for gVisor performance testing on GKE, and is now open-source. This set of benchmarks has been created and maintained by multiple contributors over the last 2 years: @zkoopmans, @EtiennePerot, @kevinGC, @ayushr2, @manninglucas, @konstantin-s-bogom. PiperOrigin-RevId: 686649688

2024-06-18

Add ioctl sniffing tool to run GPU workloads and report unsupported ioctl calls. PiperOrigin-RevId: 644197930

2023-10-25

Fix a few typos It is an idea of running codespell as part of our presubmit checks. Before enabling it for new changes, let's fix what it has found. Signed-off-by: Andrei Vagin <avagin@gmail.com>

Fix a few typos It is an idea of running codespell as part of our presubmit checks. Before enabling it for new changes, let's fix what it has found. Signed-off-by: Andrei Vagin <avagin@gmail.com>

2023-09-06

Emit SentryTcpListenEvent when the application listens on a tcp port. PiperOrigin-RevId: 562957239

Emit SentryTcpListenEvent when the application listens on a tcp port. PiperOrigin-RevId: 562957239

2023-04-10

Introduce SentryMountPromiseBlockEvent. PiperOrigin-RevId: 523233705

Introduce SentryMountPromiseBlockEvent. PiperOrigin-RevId: 523233705

2022-12-27

gVisor: Add library for exporting instrumentation data in Prometheus format. This adds a new library, `//pkg/prometheus`, which contains just enough data structures such that we can encode instrumentation information in Prometheus information. These data structures are JSON-encodable, such that they can be used over the `runsc` control channel for export (implemented in a future CL). The existing `metric.go` library gains new functionality to export its own data using this new export format. This change is part of a series of changes to support Prometheus-style metrics in `runsc`. Doing so requires making several seemingly-odd design decisions, due to the following architectural constraints: - Prometheus requires an HTTP server serving the `/metrics` endpoint. - For performance reasons, the `runsc boot` process cannot run the `netpoller` goroutine. - Since we don't want to write our own HTTP server implementation, this means the HTTP endpoint has to be served by a separate process that remains running during the lifetime of the container. - The `runsc boot` process is untrusted. - This means we cannot trust metrics data that comes out of the Sentry. Therefore, there needs to be an elaborate dance where we pre-register metric metadata before starting any untrusted workload. Then, the server relaying the metric data must verify the validity of metric values against this metric metadata. This avoids leaking metrics, cardinality blow-ups, and other such DoS vectors. - This feature needs to be easy-to-use in a typical Docker setting. - This means having the ability to just say `--metrics-server=localhost:1337` in the `runsc` runtime entry in `/etc/docker/daemon.json` and have that Just Work(TM), even when multiple containers are running. - Since only one process may listen on a port at a given time, this means the metric server needs to be able to multiplex requests out to multiple running sandboxes, and remain alive for the entire duration of either of these sandboxes. However, it should also die when there are no sandboxes, so that we don't end up with leftover metric servers lying around. - For this reason, the metrics server runs *outside* of the usual per-container cgroups. - This also saves system resources by not running one server per sandbox. - The metrics server must be exposed to the outside world, and cannot assume that its clients are trustworthy. - For this reason, a metrics server is bound to a runtime root directory, and double-checks all that the sandboxes it is asked to follow actually exist in this root directory. PiperOrigin-RevId: 498039624

gVisor: Add library for exporting instrumentation data in Prometheus format. This adds a new library, `//pkg/prometheus`, which contains just enough data structures such that we can encode instrumentation information in Prometheus information. These data structures are JSON-encodable, such that they can be used over the `runsc` control channel for export (implemented in a future CL). The existing `metric.go` library gains new functionality to export its own data using this new export format. This change is part of a series of changes to support Prometheus-style metrics in `runsc`. Doing so requires making several seemingly-odd design decisions, due to the following architectural constraints: - Prometheus requires an HTTP server serving the `/metrics` endpoint. - For performance reasons, the `runsc boot` process cannot run the `netpoller` goroutine. - Since we don't want to write our own HTTP server implementation, this means the HTTP endpoint has to be served by a separate process that remains running during the lifetime of the container. - The `runsc boot` process is untrusted. - This means we cannot trust metrics data that comes out of the Sentry. Therefore, there needs to be an elaborate dance where we pre-register metric metadata before starting any untrusted workload. Then, the server relaying the metric data must verify the validity of metric values against this metric metadata. This avoids leaking metrics, cardinality blow-ups, and other such DoS vectors. - This feature needs to be easy-to-use in a typical Docker setting. - This means having the ability to just say `--metrics-server=localhost:1337` in the `runsc` runtime entry in `/etc/docker/daemon.json` and have that Just Work(TM), even when multiple containers are running. - Since only one process may listen on a port at a given time, this means the metric server needs to be able to multiplex requests out to multiple running sandboxes, and remain alive for the entire duration of either of these sandboxes. However, it should also die when there are no sandboxes, so that we don't end up with leftover metric servers lying around. - For this reason, the metrics server runs *outside* of the usual per-container cgroups. - This also saves system resources by not running one server per sandbox. - The metrics server must be exposed to the outside world, and cannot assume that its clients are trustworthy. - For this reason, a metrics server is bound to a runtime root directory, and double-checks all that the sandboxes it is asked to follow actually exist in this root directory. PiperOrigin-RevId: 498039624

2022-12-14

Adding container_start_duration metric for container multi-container mode. Including the time when a container start request is received and the time it is completed in the ContainerStartedEvent proto message. PiperOrigin-RevId: 495390114

Adding container_start_duration metric for container multi-container mode. Including the time when a container start request is received and the time it is completed in the ContainerStartedEvent proto message. PiperOrigin-RevId: 495390114

2022-12-07

Adding metrics for start container in multi-container mode. PiperOrigin-RevId: 493655449

Adding metrics for start container in multi-container mode. PiperOrigin-RevId: 493655449

2022-11-17

Adding more trace point integration tests for the following syscalls: - Chdir - Fchdir - Setgid - Setuid - Setsid - Setresuid - Setresgid Updates #4805 PiperOrigin-RevId: 489076929

Adding more trace point integration tests for the following syscalls: - Chdir - Fchdir - Setgid - Setuid - Setsid - Setresuid - Setresgid Updates #4805 PiperOrigin-RevId: 489076929

2022-11-15

Add read/write syscalls to trace points Closes #8092 PiperOrigin-RevId: 488719448

Add read/write syscalls to trace points Closes #8092 PiperOrigin-RevId: 488719448

2022-10-07

Add container exit event. PiperOrigin-RevId: 479651998

Add container exit event. PiperOrigin-RevId: 479651998

2022-09-15

Implement sentry control commands for cgroupfs. Add sentry control commands to read and write cgroup control values. PiperOrigin-RevId: 474663678

Implement sentry control commands for cgroupfs. Add sentry control commands to read and write cgroup control values. PiperOrigin-RevId: 474663678

2022-07-07

Add Points to some syscalls Added a raw syscall points to all syscalls. Added schematized syscall points to the following syscalls: - timerfd_create - timerfd_settime - timerfd_gettime - fork, vfork - inotify_init, inotify_init1 - inotify_add_watch - inotify_rm_watch - socketpair Updates #4805 PiperOrigin-RevId: 459596784

Add Points to some syscalls Added a raw syscall points to all syscalls. Added schematized syscall points to the following syscalls: - timerfd_create - timerfd_settime - timerfd_gettime - fork, vfork - inotify_init, inotify_init1 - inotify_add_watch - inotify_rm_watch - socketpair Updates #4805 PiperOrigin-RevId: 459596784

2022-06-25

Add Points to some syscalls Added a raw syscall points to all syscalls. Added schematized syscall points to the following syscalls: - chroot - dup, dup2, dup3 - prlimit64 - eventfd, eventfd2 - signalfd, signalfd4 - bind - accept, accept4 - fcntl - pipe, pipe2 Updates #4805 PiperOrigin-RevId: 457139504

Add Points to some syscalls Added a raw syscall points to all syscalls. Added schematized syscall points to the following syscalls: - chroot - dup, dup2, dup3 - prlimit64 - eventfd, eventfd2 - signalfd, signalfd4 - bind - accept, accept4 - fcntl - pipe, pipe2 Updates #4805 PiperOrigin-RevId: 457139504

2022-05-25

Add Points to some syscalls Added a raw syscall points to all syscalls. Added schematized syscall points to the following syscalls: - Chdir - Fchdir - Setgid - Setuid - Setsid - Setresuid - Setresgid PiperOrigin-RevId: 451001973

Add Points to some syscalls Added a raw syscall points to all syscalls. Added schematized syscall points to the following syscalls: - Chdir - Fchdir - Setgid - Setuid - Setsid - Setresuid - Setresgid PiperOrigin-RevId: 451001973

Remove unused field from syscall.Read proto Updates #4805 PiperOrigin-RevId: 450802760

Remove unused field from syscall.Read proto Updates #4805 PiperOrigin-RevId: 450802760

2022-05-13

Add version handshake before communication is stablished Details on how it works is in wire.Handshake. Updates #4805 PiperOrigin-RevId: 448552448

Add version handshake before communication is stablished Details on how it works is in wire.Handshake. Updates #4805 PiperOrigin-RevId: 448552448

2022-05-06

Fire clone point for thread creation Thread creation tracking is required by Falco. Updates #4805 PiperOrigin-RevId: 447003670

Fire clone point for thread creation Thread creation tracking is required by Falco. Updates #4805 PiperOrigin-RevId: 447003670

Faster proto serialization The use of protobuf.Any is convenient, but adds to proto serialization time and number of memory allocations required to send a message. Instead, we now use an enum to indentify the message and use it to determine how to unmarshall the message on the receiveing end. It also speeds up event consuption by not requiring a map from string (proto names) to callbacks. BenchmarkProtoAny-6 115.9 ns/op 210 B/op 4 allocs/op BenchmarkProtoEnum-6 58.3 ns/op 2 B/op 1 allocs/op Updates #4805 PiperOrigin-RevId: 446879057

Faster proto serialization The use of protobuf.Any is convenient, but adds to proto serialization time and number of memory allocations required to send a message. Instead, we now use an enum to indentify the message and use it to determine how to unmarshall the message on the receiveing end. It also speeds up event consuption by not requiring a map from string (proto names) to callbacks. BenchmarkProtoAny-6 115.9 ns/op 210 B/op 4 allocs/op BenchmarkProtoEnum-6 58.3 ns/op 2 B/op 1 allocs/op Updates #4805 PiperOrigin-RevId: 446879057

2022-05-02

Add Points to some syscalls Added a raw syscall points to all syscalls. Added schematized syscall points to the following syscalls: - read - close - socket - connect - execve - creat - openat - execveat Updates #4805 PiperOrigin-RevId: 446008358

Add Points to some syscalls Added a raw syscall points to all syscalls. Added schematized syscall points to the following syscalls: - read - close - socket - connect - execve - creat - openat - execveat Updates #4805 PiperOrigin-RevId: 446008358

Add container/start context fields Updates #4805 PiperOrigin-RevId: 445976770

Add container/start context fields Updates #4805 PiperOrigin-RevId: 445976770

2022-04-29

Add support for syscall points Each syscall provides 4 different points. There is a raw syscall point that contains the syscall number and all 6 arguments, nothing else. Some syscalls can provide a schematized version of the syscall by defining a function that converts the syscall into a proto representing the syscall. Each of these flavors have a point for enter and another for exit. In both cases, the exit event adds return value and errno (if any). Updates #4805 PiperOrigin-RevId: 445510907

Add support for syscall points Each syscall provides 4 different points. There is a raw syscall point that contains the syscall number and all 6 arguments, nothing else. Some syscalls can provide a schematized version of the syscall by defining a function that converts the syscall into a proto representing the syscall. Each of these flavors have a point for enter and another for exit. In both cases, the exit event adds return value and errno (if any). Updates #4805 PiperOrigin-RevId: 445510907

2022-04-28

Add sentry/task_exit point Updates #4805 PiperOrigin-RevId: 445222912

Add sentry/task_exit point Updates #4805 PiperOrigin-RevId: 445222912

2022-04-27

Add container/start Point Updates #4805 PiperOrigin-RevId: 444983390

Add container/start Point Updates #4805 PiperOrigin-RevId: 444983390

2022-04-19

Use proto structs for seccheck points Given that in most cases points are serialized to another process, point data is now created diretly into protos. As part of this change, infrastructure to track optional and context fields was created to facilitate addition of lots of Points which is needed for upcomming of changes. Updates #4805 Currently the SST code is converting seccheck protos into SST protos in the sentry before sending it to the API. After this change, SST checker will be changed to send seccheck protos to the API and the API then converts these into SST on the way to pubsub. PiperOrigin-RevId: 442688320

Use proto structs for seccheck points Given that in most cases points are serialized to another process, point data is now created diretly into protos. As part of this change, infrastructure to track optional and context fields was created to facilitate addition of lots of Points which is needed for upcomming of changes. Updates #4805 Currently the SST code is converting seccheck protos into SST protos in the sentry before sending it to the API. After this change, SST checker will be changed to send seccheck protos to the API and the API then converts these into SST on the way to pubsub. PiperOrigin-RevId: 442688320

2022-03-23

Implement distribution metrics in the Sentry, with arbitrary number of fields. Distribution metrics are well-suited for recording "events" and the time these events take, for performance measurements. They bucket durations in buckets, and keep track of the number of samples in each bucket. As this structure also inherently keeps track of the *total* number of samples, it can be used as a simple event counter as well, obviating the need for a counter metric next to it counting the same thing. In order to be compatible with the needs of the KVM platform to track events that happen where new memory allocations would not be possible, the code for adding a sample to a distribution is optimized to be fast and allocation-free. The tradeoff there mostly comes in the form of memory, such as requiring a weird new `fieldMapper` recursive struct that acts as a lookup table for the concatenated key containing the values of all the fields for which the sample is being recorded. Since we do not expect to deal with large number of field combinations, this should not be a problem. Another tradeoff this imposes is the lack of support for a generic `Bucketer` interface allowing users to define their own bucketing scheme, as we would not be able to enforce the lack of allocations in custom `Bucketer` implementations, nor enforce `+checkescape` on them. However, since in practice all bucketing implementations will probably reside in `metric.go`, this is worked around by just having the distribution metric code refer to `Bucketer` implementations as references and call them directly (without the interface indirection). Since there is only one implementation currently (`ExponentialBucketer`), this is faster than using the interface. PiperOrigin-RevId: 436614053

Implement distribution metrics in the Sentry, with arbitrary number of fields. Distribution metrics are well-suited for recording "events" and the time these events take, for performance measurements. They bucket durations in buckets, and keep track of the number of samples in each bucket. As this structure also inherently keeps track of the *total* number of samples, it can be used as a simple event counter as well, obviating the need for a counter metric next to it counting the same thing. In order to be compatible with the needs of the KVM platform to track events that happen where new memory allocations would not be possible, the code for adding a sample to a distribution is optimized to be fast and allocation-free. The tradeoff there mostly comes in the form of memory, such as requiring a weird new `fieldMapper` recursive struct that acts as a lookup table for the concatenated key containing the values of all the fields for which the sample is being recorded. Since we do not expect to deal with large number of field combinations, this should not be a problem. Another tradeoff this imposes is the lack of support for a generic `Bucketer` interface allowing users to define their own bucketing scheme, as we would not be able to enforce the lack of allocations in custom `Bucketer` implementations, nor enforce `+checkescape` on them. However, since in practice all bucketing implementations will probably reside in `metric.go`, this is worked around by just having the distribution metric code refer to `Bucketer` implementations as references and call them directly (without the interface indirection). Since there is only one implementation currently (`ExponentialBucketer`), this is faster than using the interface. PiperOrigin-RevId: 436614053

2021-10-25

Add support for containerd 1.5 "cri.runtimeoptions.v1" moved to "runtimeoptions.v1" and containerd configuration format version 2 is required. Updates #6449 PiperOrigin-RevId: 405474653

Add support for containerd 1.5 "cri.runtimeoptions.v1" moved to "runtimeoptions.v1" and containerd configuration format version 2 is required. Updates #6449 PiperOrigin-RevId: 405474653

2021-08-18

Add control configs Also plumber the controls through runsc PiperOrigin-RevId: 391594318

Add control configs Also plumber the controls through runsc PiperOrigin-RevId: 391594318

2021-07-23

Add control configs PiperOrigin-RevId: 386340922

2021-07-09

Add TimeToRecover metric to record time spent by the connection in recovery. - The new sentry metric will record the duration when the connection is in Fast/SACK recovery and RTO recovery. This metric will help us to compare between different loss recovery algorithms such as Reno, SACK and RACK. - Added a new field in the TCP sender to record the start time of recovery. - Made changes to create sentry metrics with Microseconds unit. PiperOrigin-RevId: 383539850

2021-07-07

Sentry: Measure the time it takes to initialize the Sentry. PiperOrigin-RevId: 383472507

Sentry: Measure the time it takes to initialize the Sentry. PiperOrigin-RevId: 383472507

2021-04-16

Add field support to the sentry metrics. Fields allow counter metrics to have multiple tabular values. At most one field is supported at the moment. PiperOrigin-RevId: 368767040

Add field support to the sentry metrics. Fields allow counter metrics to have multiple tabular values. At most one field is supported at the moment. PiperOrigin-RevId: 368767040

2021-03-15

Packetimpact test for ACK to OTW Seq segments behavior in CLOSING TCP, in CLOSING state, MUST send an ACK with next expected SEQ number after receiving any segment with OTW SEQ number and remain in the same state. While I am here, I also changed shutdown to behave the same as other calls in posix_server. PiperOrigin-RevId: 362976955

Packetimpact test for ACK to OTW Seq segments behavior in CLOSING TCP, in CLOSING state, MUST send an ACK with next expected SEQ number after receiving any segment with OTW SEQ number and remain in the same state. While I am here, I also changed shutdown to behave the same as other calls in posix_server. PiperOrigin-RevId: 362976955

2021-02-25

Move SetNonblocking into posix_server - open flags can be different on different OSs, by putting SetNonblocking into the posix_server rather than the testbench, we can always get the right value for O_NONBLOCK - merged the tcp_queue_{send,receive}_in_syn_sent into a single file PiperOrigin-RevId: 359620630