summaryrefslogtreecommitdiffhomepage
path: root/pkg/tcpip
AgeCommit message (Collapse)Author
2020-09-09Merge release-20200818.0-137-g8d3551da6 (automated)gVisor bot
2020-09-08Merge release-20200818.0-135-ga17d083f3 (automated)gVisor bot
2020-09-08Merge release-20200818.0-133-g682c0edcd (automated)gVisor bot
2020-09-08Merge release-20200818.0-132-gc8f1ce288 (automated)gVisor bot
2020-09-08Merge release-20200818.0-131-g284e6811e (automated)gVisor bot
2020-09-08Merge release-20200818.0-130-ga3b87a0ce (automated)gVisor bot
2020-09-08Increase resolution timeout for TestCacheResolutionSam Balana
Fixes pkg/tcpip/stack:stack_test flake experienced while running TestCacheResolution with gotsan. This occurs when the test-runner takes longer than the resolution timeout to call linkAddrCache.get. In this test we don't care about the resolution timeout, so set it to the maximum and rely on test-runner timeouts to avoid deadlocks. PiperOrigin-RevId: 330566250
2020-09-08Merge release-20200818.0-128-g38cdb0579 (automated)gVisor bot
2020-09-08Fix data race in tcp.GetSockOpt.Bhasker Hariharan
e.ID can't be read without holding e.mu. GetSockOpt was reading e.ID when looking up OriginalDst without holding e.mu. PiperOrigin-RevId: 330562293
2020-09-08Merge release-20200818.0-127-gd35f07b36 (automated)gVisor bot
2020-09-08Improve type safety for transport protocol optionsGhanan Gowripalan
The existing implementation for TransportProtocol.{Set}Option take arguments of an empty interface type which all types (implicitly) implement; any type may be passed to the functions. This change introduces marker interfaces for transport protocol options that may be set or queried which transport protocol option types implement to ensure that invalid types are caught at compile time. Different interfaces are used to allow the compiler to enforce read-only or set-only socket options. RELNOTES: n/a PiperOrigin-RevId: 330559811
2020-09-08Merge release-20200818.0-126-gd84ec6c42 (automated)gVisor bot
2020-09-04Merge release-20200818.0-124-g2202812e0 (automated)gVisor bot
2020-09-04Merge release-20200818.0-122-gb6d6a120d (automated)gVisor bot
2020-09-04Merge release-20200818.0-121-g805861ca3 (automated)gVisor bot
2020-09-03Use fine-grained mutex for stack.cleanupEndpoints.Bhasker Hariharan
stack.cleanupEndpoints is protected by the stack.mu but that can cause contention as the stack mutex is already acquired in a lot of hot paths during new endpoint creation /cleanup etc. Moving this to a fine grained mutex should reduce contention on the stack.mu. PiperOrigin-RevId: 330026151
2020-09-03Merge release-20200818.0-120-g76e51c8b9 (automated)gVisor bot
2020-09-03Use atomic.Value for Stack.tcpProbeFunc.Jamie Liu
b/166980357#comment56 shows: - 837 goroutines blocked in: gvisor/pkg/sync/sync.(*RWMutex).Lock gvisor/pkg/tcpip/stack/stack.(*Stack).StartTransportEndpointCleanup gvisor/pkg/tcpip/transport/tcp/tcp.(*endpoint).cleanupLocked gvisor/pkg/tcpip/transport/tcp/tcp.(*endpoint).completeWorkerLocked gvisor/pkg/tcpip/transport/tcp/tcp.(*endpoint).protocolMainLoop.func1 gvisor/pkg/tcpip/transport/tcp/tcp.(*endpoint).protocolMainLoop - 695 goroutines blocked in: gvisor/pkg/sync/sync.(*RWMutex).Lock gvisor/pkg/tcpip/stack/stack.(*Stack).CompleteTransportEndpointCleanup gvisor/pkg/tcpip/transport/tcp/tcp.(*endpoint).cleanupLocked gvisor/pkg/tcpip/transport/tcp/tcp.(*endpoint).completeWorkerLocked gvisor/pkg/tcpip/transport/tcp/tcp.(*endpoint).protocolMainLoop.func1 gvisor/pkg/tcpip/transport/tcp/tcp.(*endpoint).protocolMainLoop - 3882 goroutines blocked in: gvisor/pkg/sync/sync.(*RWMutex).Lock gvisor/pkg/tcpip/stack/stack.(*Stack).GetTCPProbe gvisor/pkg/tcpip/transport/tcp/tcp.newEndpoint gvisor/pkg/tcpip/transport/tcp/tcp.(*protocol).NewEndpoint gvisor/pkg/tcpip/stack/stack.(*Stack).NewEndpoint All of these are contending on Stack.mu. Stack.StartTransportEndpointCleanup() and Stack.CompleteTransportEndpointCleanup() insert/delete TransportEndpoints in a map (Stack.cleanupEndpoints), and the former also does endpoint unregistration while holding Stack.mu, so it's not immediately clear how feasible it is to replace the map with a mutex-less implementation or how much doing so would help. However, Stack.GetTCPProbe() just reads a function object (Stack.tcpProbeFunc) that is almost always nil (as far as I can tell, Stack.AddTCPProbe() is only called in tests), and it's called for every new TCP endpoint. So converting it to an atomic.Value should significantly reduce contention on Stack.mu, improving TCP endpoint creation latency and allowing TCP endpoint cleanup to proceed. PiperOrigin-RevId: 330004140
2020-09-03Merge release-20200818.0-119-g30c20df76 (automated)gVisor bot
2020-09-03Merge release-20200818.0-118-g319ce6736 (automated)gVisor bot
2020-09-03Merge release-20200818.0-117-ga8c174c04 (automated)gVisor bot
2020-09-03Merge release-20200818.0-115-gb69352245 (automated)gVisor bot
2020-09-02Fix Accept to not return error for sockets in accept queue.Bhasker Hariharan
Accept on gVisor will return an error if a socket in the accept queue was closed before Accept() was called. Linux will return the new fd even if the returned socket is already closed by the peer say due to a RST being sent by the peer. This seems to be intentional in linux more details on the github issue. Fixes #3780 PiperOrigin-RevId: 329828404
2020-09-02Merge release-20200818.0-113-g0ca0d8e01 (automated)gVisor bot
2020-09-02Merge release-20200818.0-112-g5c6601120 (automated)gVisor bot
2020-09-02Merge release-20200818.0-110-gb9b6660dc (automated)gVisor bot
2020-09-02Merge release-20200818.0-109-g8ab08cdc0 (automated)gVisor bot
2020-09-02Merge release-20200818.0-108-ga0e431038 (automated)gVisor bot
2020-09-02Merge release-20200818.0-106-g563f28b7d (automated)gVisor bot
2020-09-02Merge release-20200818.0-104-g40faeaa18 (automated)gVisor bot
2020-09-01Fix handling of unacceptable ACKs during close.Mithun Iyer
On receiving an ACK with unacceptable ACK number, in a closing state, TCP, needs to reply back with an ACK with correct seq and ack numbers and remain in same state. This change is as per RFC793 page 37, but with a difference that it does not apply to ESTABLISHED state, just as in Linux. Also add more tests to check for OTW sequence number and unacceptable ack numbers in these states. Fixes #3785 PiperOrigin-RevId: 329616283
2020-09-02Merge release-20200818.0-103-gc67d8ece0 (automated)gVisor bot
2020-09-01Merge release-20200818.0-102-g2eaf54dd5 (automated)gVisor bot
2020-09-01Merge release-20200818.0-101-g04c284f8c (automated)gVisor bot
2020-09-01Merge release-20200818.0-100-g723fb5c11 (automated)gVisor bot
2020-09-01Merge release-20200818.0-99-g71589b7f7 (automated)gVisor bot
2020-09-01Merge release-20200818.0-98-g0eae08bc9 (automated)gVisor bot
2020-09-01Automated rollback of changelist 328350576Nayana Bidari
PiperOrigin-RevId: 329526153
2020-09-01Merge release-20200818.0-97-gf4be726fd (automated)gVisor bot
2020-09-01Merge release-20200818.0-96-g674843849 (automated)gVisor bot
2020-09-01Merge release-20200818.0-95-g101c97d6f (automated)gVisor bot
2020-08-31Merge release-20200818.0-94-g170560cec (automated)gVisor bot
2020-08-31Merge release-20200818.0-93-g6cdfa4fee (automated)gVisor bot
2020-08-31Merge release-20200818.0-92-g9d0d82088 (automated)gVisor bot
2020-08-31Merge release-20200818.0-89-ga3d189301 (automated)gVisor bot
2020-08-29Merge release-20200818.0-88-g3bee863ae (automated)gVisor bot
2020-08-29Merge release-20200818.0-87-gf6ddcbefa (automated)gVisor bot
2020-08-28Merge release-20200818.0-86-gd3057717d (automated)gVisor bot
2020-08-28Merge release-20200818.0-85-gd5787f628 (automated)gVisor bot
2020-08-28Don't bind loopback to all IPs in an IPv6 subnetGhanan Gowripalan
An earlier change considered the loopback bound to all addresses in an assigned subnet. This should have only be done for IPv4 to maintain compatability with Linux: ``` $ ip addr show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group ... link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever $ ping 2001:db8::1 PING 2001:db8::1(2001:db8::1) 56 data bytes ^C --- 2001:db8::1 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3062ms $ ping 2001:db8::2 PING 2001:db8::2(2001:db8::2) 56 data bytes ^C --- 2001:db8::2 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2030ms $ sudo ip addr add 2001:db8::1/64 dev lo $ ping 2001:db8::1 PING 2001:db8::1(2001:db8::1) 56 data bytes 64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=0.055 ms 64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=0.074 ms 64 bytes from 2001:db8::1: icmp_seq=3 ttl=64 time=0.073 ms 64 bytes from 2001:db8::1: icmp_seq=4 ttl=64 time=0.071 ms ^C --- 2001:db8::1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3075ms rtt min/avg/max/mdev = 0.055/0.068/0.074/0.007 ms $ ping 2001:db8::2 PING 2001:db8::2(2001:db8::2) 56 data bytes From 2001:db8::1 icmp_seq=1 Destination unreachable: No route From 2001:db8::1 icmp_seq=2 Destination unreachable: No route From 2001:db8::1 icmp_seq=3 Destination unreachable: No route From 2001:db8::1 icmp_seq=4 Destination unreachable: No route ^C --- 2001:db8::2 ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3070ms ``` Test: integration_test.TestLoopbackAcceptAllInSubnet PiperOrigin-RevId: 329011566