summaryrefslogtreecommitdiffhomepage
path: root/pkg/tcpip/link/tun
AgeCommit message (Collapse)Author
2020-12-28Merge release-20201208.0-89-g3ff7324df (automated)gVisor bot
2020-12-22Invoke address resolution upon subsequent traffic to Failed neighborPeter Johnston
Removes the period of time in which subseqeuent traffic to a Failed neighbor immediately fails with ErrNoLinkAddress. A Failed neighbor is one in which address resolution fails; or in other words, the neighbor's IP address cannot be translated to a MAC address. This means removing the Failed state for linkAddrCache and allowing transitiong out of Failed into Incomplete for neighborCache. Previously, both caches would transition entries to Failed after address resolution fails. In this state, any subsequent traffic requested within an unreachable time would immediately fail with ErrNoLinkAddress. This does not follow RFC 4861 section 7.3.3: If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that neighbor invokes the next-hop determination procedure again. Invoking next-hop determination at this point ensures that alternate default routers are tried. The API for getting a link address for a given address, whether through the link address cache or the neighbor table, is updated to optionally take a callback which will be called when address resolution completes. This allows `Route` to handle completing link resolution internally, so callers of (*Route).Resolve (e.g. endpoints) don’t have to keep track of when it completes and update the Route accordingly. This change also removes the wakers from LinkAddressCache, NeighborCache, and Route in favor of the callbacks, and callers that previously used a waker can now just pass a callback to (*Route).Resolve that will notify the waker on resolution completion. Fixes #4796 Startblock: has LGTM from sbalana and then add reviewer ghanan PiperOrigin-RevId: 348597478
2020-12-12Merge release-20201208.0-36-g1e92732eb (automated)gVisor bot
2020-12-03Merge release-20201130.0-31-g3ff1aef54 (automated)gVisor bot
2020-12-03Make `stack.Route` thread safePeter Johnston
Currently we rely on the user to take the lock on the endpoint that owns the route, in order to modify it safely. We can instead move `Route.RemoteLinkAddress` under `Route`'s mutex, and allow non-locking and thread-safe access to other fields of `Route`. PiperOrigin-RevId: 345461586
2020-11-16Merge release-20201109.0-51-gcc5cfce4c (automated)gVisor bot
2020-11-16Remove ARP address workaroundGhanan Gowripalan
- Make AddressableEndpoint optional for NetworkEndpoint. Not all NetworkEndpoints need to support addressing (e.g. ARP), so AddressableEndpoint should only be implemented for protocols that support addressing such as IPv4 and IPv6. With this change, tcpip.ErrNotSupported will be returned by the stack when attempting to modify addresses on a network endpoint that does not support addressing. Now that packets are fully handled at the network layer, and (with this change) addresses are optional for network endpoints, we no longer need the workaround for ARP where a fake ARP address was added to each NIC that performs ARP so that packets would be delivered to the ARP layer. PiperOrigin-RevId: 342722547
2020-11-09Merge release-20201030.0-53-g0fb5353e4 (automated)gVisor bot
2020-11-09Initialize references with a value of 1.Dean Deng
This lets us avoid treating a value of 0 as one reference. All references using the refsvfs2 template must call InitRefs() before the reference is incremented/decremented, or else a panic will occur. Therefore, it should be pretty easy to identify missing InitRef calls during testing. Updates #1486. PiperOrigin-RevId: 341411151
2020-10-29Merge release-20201019.0-95-g3b4674ffe (automated)gVisor bot
2020-10-23Merge release-20201019.0-34-g9ca66ec59 (automated)gVisor bot
2020-10-23Rewrite reference leak checker without finalizers.Dean Deng
Our current reference leak checker uses finalizers to verify whether an object has reached zero references before it is garbage collected. There are multiple problems with this mechanism, so a rewrite is in order. With finalizers, there is no way to guarantee that a finalizer will run before the program exits. When an unreachable object with a finalizer is garbage collected, its finalizer will be added to a queue and run asynchronously. The best we can do is run garbage collection upon sandbox exit to make sure that all finalizers are enqueued. Furthermore, if there is a chain of finalized objects, e.g. A points to B points to C, garbage collection needs to run multiple times before all of the finalizers are enqueued. The first GC run will register the finalizer for A but not free it. It takes another GC run to free A, at which point B's finalizer can be registered. As a result, we need to run GC as many times as the length of the longest such chain to have a somewhat reliable leak checker. Finally, a cyclical chain of structs pointing to one another will never be garbage collected if a finalizer is set. This is a well-known issue with Go finalizers (https://github.com/golang/go/issues/7358). Using leak checking on filesystem objects that produce cycles will not work and even result in memory leaks. The new leak checker stores reference counted objects in a global map when leak check is enabled and removes them once they are destroyed. At sandbox exit, any remaining objects in the map are considered as leaked. This provides a deterministic way of detecting leaks without relying on the complexities of finalizers and garbage collection. This approach has several benefits over the former, including: - Always detects leaks of objects that should be destroyed very close to sandbox exit. The old checker very rarely detected these leaks, because it relied on garbage collection to be run in a short window of time. - Panics if we forgot to enable leak check on a ref-counted object (we will try to remove it from the map when it is destroyed, but it will never have been added). - Can store extra logging information in the map values without adding to the size of the ref count struct itself. With the size of just an int64, the ref count object remains compact, meaning frequent operations like IncRef/DecRef are more cache-efficient. - Can aggregate leak results in a single report after the sandbox exits. Instead of having warnings littered in the log, which were non-deterministically triggered by garbage collection, we can print all warning messages at once. Note that this could also be a limitation--the sandbox must exit properly for leaks to be detected. Some basic benchmarking indicates that this change does not significantly affect performance when leak checking is enabled, which is understandable since registering/unregistering is only done once for each filesystem object. Updates #1486. PiperOrigin-RevId: 338685972
2020-10-09Merge release-20200928.0-78-g743327817 (automated)gVisor bot
2020-10-09Merge release-20200928.0-77-g257703c05 (automated)gVisor bot
2020-10-09Automated rollback of changelist 336304024Ghanan Gowripalan
PiperOrigin-RevId: 336339194
2020-10-09Merge release-20200928.0-74-g8566decab (automated)gVisor bot
2020-10-09Automated rollback of changelist 336185457Bhasker Hariharan
PiperOrigin-RevId: 336304024
2020-10-08Merge release-20200928.0-71-g6768e6c59 (automated)gVisor bot
2020-10-08Do not resolve routes immediatelyGhanan Gowripalan
When a response needs to be sent to an incoming packet, the stack should consult its neighbour table to determine the remote address's link address. When an entry does not exist in the stack's neighbor table, the stack should queue the packet while link resolution completes. See comments. PiperOrigin-RevId: 336185457
2020-10-08Merge release-20200928.0-66-ga55bd73d4 (automated)gVisor bot
2020-09-23Merge release-20200914.0-137-g99decaadd (automated)gVisor bot
2020-09-23Merge release-20200914.0-136-gb54dbdfdc (automated)gVisor bot
2020-09-23Merge release-20200914.0-135-gc0f21bb19 (automated)gVisor bot
2020-09-22Merge release-20200914.0-134-gcf3cef117 (automated)gVisor bot
2020-09-22Merge release-20200914.0-133-g20dc83c9e (automated)gVisor bot
2020-09-22Merge release-20200914.0-132-g778c36717 (automated)gVisor bot
2020-09-22Merge release-20200914.0-130-g13a9a622e (automated)gVisor bot
2020-09-22Merge release-20200914.0-129-gf134f873f (automated)gVisor bot
2020-09-21Merge release-20200914.0-127-g059d90b9f (automated)gVisor bot
2020-09-21Merge release-20200914.0-125-g06dbd5b7b (automated)gVisor bot
2020-09-21Merge release-20200914.0-124-g10dcefbc7 (automated)gVisor bot
2020-09-21Merge release-20200914.0-123-ga129204cf (automated)gVisor bot
2020-09-21Merge release-20200914.0-122-gd72022373 (automated)gVisor bot
2020-09-18Merge release-20200907.0-153-g4ba86e625 (automated)gVisor bot
2020-09-18Merge release-20200907.0-151-g6c9989cb8 (automated)gVisor bot
2020-09-18Merge release-20200907.0-150-gc23e39f41 (automated)gVisor bot
2020-09-18Merge release-20200907.0-149-gb8ba0893e (automated)gVisor bot
2020-09-18Merge release-20200907.0-148-gca4ecf481 (automated)gVisor bot
2020-09-18Merge release-20200907.0-147-gf911b43f0 (automated)gVisor bot
2020-09-18Merge release-20200907.0-146-gddf37cb19 (automated)gVisor bot
2020-09-18Merge release-20200907.0-144-gdedef4392 (automated)gVisor bot
2020-09-18Merge release-20200907.0-142-gfcf8d7c6d (automated)gVisor bot
2020-09-18Merge release-20200907.0-140-gef7d9a6fc (automated)gVisor bot
2020-09-18Merge release-20200907.0-139-g313e1988c (automated)gVisor bot
2020-09-18Merge release-20200907.0-138-g360006d89 (automated)gVisor bot
2020-09-18Merge release-20200907.0-137-g07d832dbb (automated)gVisor bot
2020-09-18Merge release-20200907.0-136-g2fbd31e72 (automated)gVisor bot
2020-09-18Merge release-20200907.0-134-gd34bda027 (automated)gVisor bot
2020-09-18Merge release-20200907.0-133-gc0b74be54 (automated)gVisor bot
2020-09-18Merge release-20200907.0-132-g23fcbd872 (automated)gVisor bot