summaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)Author
2020-11-19Merge release-20201109.0-91-g49adf36ed (automated)gVisor bot
2020-11-19Fix possible panic due to bad data.Julian Elischer
Found by a Fuzzer. Reported-by: syzbot+619fa10be366d553ef7f@syzkaller.appspotmail.com PiperOrigin-RevId: 343379575
2020-11-19Merge release-20201109.0-90-g209a95a35 (automated)gVisor bot
2020-11-19Propagate IP address prefix from host to netstackFabricio Voznika
Closes #4022 PiperOrigin-RevId: 343378647
2020-11-19Merge release-20201109.0-89-g3454d5721 (automated)gVisor bot
2020-11-19Require sync.Mutex to lock and unlock from the same goroutineMichael Pratt
We would like to track locks ordering to detect ordering violations. Detecting violations is much simpler if mutexes must be unlocked by the same goroutine that locked them. Thus, as a first step to tracking lock ordering, add this lock/unlock requirement to gVisor's sync.Mutex. This is more strict than the Go standard library's sync.Mutex, but initial testing indicates only a single lock that is used across goroutines. The new sync.CrossGoroutineMutex relaxes the requirement (but will not provide lock order checking). Due to the additional overhead, enforcement is only enabled with the "checklocks" build tag. Build with this tag using: bazel build --define=gotags=checklocks ... From my spot-checking, this has no changed inlining properties when disabled. Updates #4804 PiperOrigin-RevId: 343370200
2020-11-19Merge release-20201109.0-88-g27ee4fe76 (automated)gVisor bot
2020-11-19Don't hold AddressEndpoints for multicast addressesGhanan Gowripalan
Group addressable endpoints can simply check if it has joined the multicast group without maintaining address endpoints. This also helps remove the dependency on AddressableEndpoint from GroupAddressableEndpoint. Now that group addresses are not tracked with address endpoints, we can avoid accidentally obtaining a route with a multicast local address. PiperOrigin-RevId: 343336912
2020-11-19Merge release-20201109.0-87-g332671c33 (automated)gVisor bot
2020-11-19Remove unused NoChecksumOptionBruno Dal Bo
Migration to unified socket options left this behind. PiperOrigin-RevId: 343305434
2020-11-19Merge release-20201109.0-86-ge8df1ccef (automated)gVisor bot
2020-11-19Fix some code not using NewPacketBuffer for creating a PacketBuffer.Ting-Yu Wang
PiperOrigin-RevId: 343299993
2020-11-19Merge release-20201109.0-85-g74bc6e56c (automated)gVisor bot
2020-11-18[vfs] kernfs: Do not panic if destroyed dentry is cached.Ayush Ranjan
If a kernfs user does not cache dentries, then cacheLocked will destroy the dentry. The current DecRef implementation will be racy in this case as the following can happen: - Goroutine 1 calls DecRef and decreases ref count from 1 to 0. - Goroutine 2 acquires d.fs.mu for reading and calls IncRef and increasing the ref count from 0 to 1. - Goroutine 2 releases d.fs.mu and calls DecRef again decreasing ref count from 1 to 0. - Goroutine 1 now acquires d.fs.mu and calls cacheLocked which destroys the dentry. - Goroutine 2 now acquires d.fs.mu and calls cacheLocked to find that the dentry is already destroyed! Earlier we would panic in this case, we could instead just return instead of adding complexity to handle this race. This is similar to what the gofer client does. We do not want to lock d.fs.mu in the case that the filesystem caches dentries (common case as procfs and sysfs do this) to prevent congestion due to lock contention. PiperOrigin-RevId: 343229496
2020-11-19Merge release-20201109.0-84-ge5650d124 (automated)gVisor bot
2020-11-18[netstack] Move SO_KEEPALIVE and SO_ACCEPTCONN option to SocketOptions.Ayush Ranjan
PiperOrigin-RevId: 343217712
2020-11-19Merge release-20201109.0-83-g93750a600 (automated)gVisor bot
2020-11-18Remove unused methods from stack.RouteGhanan Gowripalan
PiperOrigin-RevId: 343211553
2020-11-19Merge release-20201109.0-82-g764504c38 (automated)gVisor bot
2020-11-18runsc: check whether cgroup exists or not for each controllerAndrei Vagin
We have seen a case when a memory cgroup exists but a perf_event one doesn't. Reported-by: syzbot+f31468b61d1a27e629dc@syzkaller.appspotmail.com Reported-by: syzbot+1f163ec0321768f1497e@syzkaller.appspotmail.com PiperOrigin-RevId: 343200070
2020-11-19Merge release-20201109.0-81-g3a16b829c (automated)gVisor bot
2020-11-18Port filesystem metrics to VFS2.Jamie Liu
PiperOrigin-RevId: 343196927
2020-11-19Merge release-20201109.0-80-g7158095d6 (automated)gVisor bot
2020-11-18Fix race condition in multi-container wait testFabricio Voznika
Container is not thread-safe, locking must be done in the caller. The test was calling Container.Wait() from multiple threads with no synchronization. Also removed Container.WaitPID from test because the process might have already existed when wait is called. PiperOrigin-RevId: 343176280
2020-11-18Merge release-20201109.0-79-gdf37babd5 (automated)gVisor bot
2020-11-18[netstack] Move SO_REUSEPORT and SO_REUSEADDR option to SocketOptions.Ayush Ranjan
This changes also introduces: - `SocketOptionsHandler` interface which can be implemented by endpoints to handle endpoint specific behavior on SetSockOpt. This is analogous to what Linux does. - `DefaultSocketOptionsHandler` which is a default implementation of the above. This is embedded in all endpoints so that we don't have to uselessly implement empty functions. Endpoints with specific behavior can override the embedded method by manually defining its own implementation. PiperOrigin-RevId: 343158301
2020-11-18Merge release-20201109.0-78-gc85bba038 (automated)gVisor bot
2020-11-18Automated rollback of changelist 342700744Nayana Bidari
PiperOrigin-RevId: 343152780
2020-11-18Merge release-20201109.0-77-g3e73c519a (automated)gVisor bot
2020-11-18[netstack] Move SO_NO_CHECK option to SocketOptions.Ayush Ranjan
PiperOrigin-RevId: 343146856
2020-11-18Merge release-20201109.0-76-gd2b701758 (automated)gVisor bot
2020-11-18Remove the redundant containerIP parameterZeling Feng
PiperOrigin-RevId: 343144023
2020-11-18Merge release-20201109.0-75-g60b97bfda (automated)gVisor bot
2020-11-18Fix loopback subnet routing errorGhanan Gowripalan
Packets should be properly routed when sending packets to addresses in the loopback subnet which are not explicitly assigned to the loopback interface. Tests: - integration_test.TestLoopbackAcceptAllInSubnetUDP - integration_test.TestLoopbackAcceptAllInSubnetTCP PiperOrigin-RevId: 343135643
2020-11-18Merge release-20201109.0-74-gc978ab047 (automated)gVisor bot
2020-11-18Merge pull request #4791 from lubinszARM:pr_pt_uppergVisor bot
PiperOrigin-RevId: 343130667
2020-11-18Merge release-20201109.0-72-gd6e788a8d (automated)gVisor bot
2020-11-18Add a few syslog messages.Etienne Perot
PiperOrigin-RevId: 343123278
2020-11-18Merge release-20201109.0-71-gfc342fb43 (automated)gVisor bot
2020-11-18[netstack] Move SO_PASSCRED option to SocketOptions.Ayush Ranjan
This change also makes the following fixes: - Make SocketOptions use atomic operations instead of having to acquire/drop locks upon each get/set option. - Make documentation more consistent. - Remove tcpip.SocketOptions from socketOpsCommon because it already exists in transport.Endpoint. - Refactors get/set socket options tests to be easily extendable. PiperOrigin-RevId: 343103780
2020-11-18Merge release-20201109.0-70-g87ed61ea0 (automated)gVisor bot
2020-11-18Remove outdated nogo exception.Dean Deng
PiperOrigin-RevId: 343096420
2020-11-18Merge release-20201109.0-69-g9d148627f (automated)gVisor bot
2020-11-18Introduce stack.WritePacketToRemote, remove LinkEndpoint.WriteRawPacketBruno Dal Bo
Redefine stack.WritePacket into stack.WritePacketToRemote which lets the NIC decide whether to append link headers. PiperOrigin-RevId: 343071742
2020-11-18Merge release-20201109.0-68-ga5e3fd1b2 (automated)gVisor bot
2020-11-17Remove sniffer from gonet_test.Bhasker Hariharan
This was added by mistake in cl/342868552. PiperOrigin-RevId: 343021431
2020-11-18Merge release-20201109.0-67-g0e32d98f3 (automated)gVisor bot
2020-11-17Fix endpoint.Read() when endpoint is in StateError.Bhasker Hariharan
If the endpoint is in StateError but e.hardErrorLocked() returns nil then return ErrClosedForRecieve. This can happen if a concurrent write on the same endpoint was in progress when the endpoint transitioned to an error state. PiperOrigin-RevId: 343018257
2020-11-18Merge release-20201109.0-66-gee6dd8cb9 (automated)gVisor bot
2020-11-17Merge pull request #4840 from lubinszARM:pr_fpsimd_1gVisor bot
PiperOrigin-RevId: 343000335