Age | Commit message (Collapse) | Author |
|
|
|
Between when runExitNotify.execute() returns nil (indicating that the task
goroutine should exit) and when Task.run() advances Task.gosched.State to
TaskGoroutineNonexistent (indicating that the task goroutine is exiting), there
is a race window in which the Task is waitable (since TaskSet.mu is unlocked
and Task.exitParentNotified is true) but will be reported by /proc/[pid]/status
as running. Close the window by checking Task.exitState before task goroutine
exit.
PiperOrigin-RevId: 378711484
|
|
|
|
Fixes #214
PiperOrigin-RevId: 378680466
|
|
|
|
PiperOrigin-RevId: 378677167
|
|
|
|
PiperOrigin-RevId: 378607458
|
|
|
|
Updates #214
PiperOrigin-RevId: 378594929
|
|
|
|
There were also other duplicate definitions of the same struct that I have now
removed.
Updates #214
PiperOrigin-RevId: 378579954
|
|
|
|
This lets us close a tracking bug that's too widely-scoped to be reasonably
finished.
PiperOrigin-RevId: 378563203
|
|
|
|
PiperOrigin-RevId: 378546551
|
|
|
|
This is a good Go convention that we should follow.
PiperOrigin-RevId: 378538679
|
|
|
|
It defaults to true and setting it to false can cause filesytem corruption.
PiperOrigin-RevId: 378518663
|
|
|
|
PiperOrigin-RevId: 378506076
|
|
|
|
The bug id was not adding anything relevant here
PiperOrigin-RevId: 378485983
|
|
|
|
It's in VFS1 code, so we probably will not do it.
PiperOrigin-RevId: 378474174
|
|
Running multiple instances of netstack in the same network namespace can
cause collisions when enabling packet fanout for fdbased endpoints. The
only bulletproof fix is to run in different network namespaces, but by
using `getpid()` instead of 0 as the fanout ID starting point we can
avoid collisions in the common case, particularly when
testing/experimenting.
Addresses #6124
|
|
|
|
PiperOrigin-RevId: 378306356
|
|
|
|
PiperOrigin-RevId: 378262750
|
|
Signed-off-by: Esteban Blanc <esteban.blanc@lse.epita.fr>
|
|
Signed-off-by: Esteban Blanc <esteban.blanc@lse.epita.fr>
|
|
|
|
...as address add/removal updates multicast group memberships and NDP
state.
This partially reverts the change made to the IPv6 endpoint in
https://github.com/google/gvisor/commit/ebebb3059f7c5dbe42af85715f1c51c.
PiperOrigin-RevId: 378061726
|
|
|
|
Netstack behaves as if SO_OOBINLINE is always set, and was logging an
unsupported syscall event if the app tries to disable it. We don't have a real
use case for TCP urgent mechanisms (and RFC6093 says apps SHOULD NOT use it).
This CL keeps the current behavior, but removes the unsupported syscall event.
Fixes #6123
PiperOrigin-RevId: 378026059
|
|
|
|
A memory that is allocated with calloc has to be freed.
PiperOrigin-RevId: 378001409
|
|
|
|
PiperOrigin-RevId: 377975013
|
|
|
|
PiperOrigin-RevId: 377966969
|
|
|
|
The go branch requires that indirect dependencies be specified in go.mod/go.sum
as well as direct dependencies in order to work. This includes dependencies
that arise from code that is normally generated or otherwise handled by bazel.
Fixes #6053
PiperOrigin-RevId: 377955230
|
|
|
|
As per https://linux.die.net/man/8/iptables,
```
Parameters
-i, --in-interface [!] name
Name of an interface via which a packet was received (only for
packets entering the INPUT, FORWARD and PREROUTING chains).
```
Before this change, iptables would use the NIC that a packet was
delivered to after forwarding a packet locally (when forwarding is
enabled) instead of the NIC the packet arrived at.
Updates #170, #3549.
Test: iptables_test.TestInputHookWithLocalForwarding
PiperOrigin-RevId: 377714971
|
|
|
|
If the ACK completing the handshake has FIN or data, requeue the segment
for further processing by the newly established endpoint. Otherwise,
the segments would have to be retransmitted by the peer to be processed
by the established endpoint. Doing this, keeps the behavior in parity
with Linux.
This also addresses a test flake with TCPNonBlockingConnectClose where
the ACK (completing the handshake) and multiple retransmitted FINACKs
from the peer could be dropped by the listener, when using syncookies
and the accept queue is full. The handshake could eventually get
completed with a retransmitted FINACK, without actual processing of
FIN. This can cause the poll with POLLRDHUP on the accepted socket to
sometimes time out before the next FINACK retransmission.
PiperOrigin-RevId: 377651695
|
|
|