summaryrefslogtreecommitdiffhomepage
path: root/pkg
AgeCommit message (Collapse)Author
2020-09-08Merge release-20200818.0-125-gfada564c8 (automated)gVisor bot
2020-09-04Merge release-20200818.0-124-g2202812e0 (automated)gVisor bot
2020-09-04Simplify FD handling for container start/execFabricio Voznika
VFS1 and VFS2 host FDs have different dupping behavior, making error prone to code for both. Change the contract so that FDs are released as they are used, so the caller can simple defer a block that closes all remaining files. This also addresses handling of partial failures. With this fix, more VFS2 tests can be enabled. Updates #1487 PiperOrigin-RevId: 330112266
2020-09-04Merge release-20200818.0-123-gc564293b6 (automated)gVisor bot
2020-09-03Adjust input file offset when sendfile only completes a partial write.Dean Deng
Fixes #3779. PiperOrigin-RevId: 330057268
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-116-g86c1ae095 (automated)gVisor bot
2020-09-02Add support to run packetimpact tests against FuchsiaZeling Feng
blaze test <test_name>_fuchsia_test will run the corresponding packetimpact test against fuchsia. PiperOrigin-RevId: 329835290
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-03Merge release-20200818.0-114-g1fec86193 (automated)gVisor bot
2020-09-02[vfs] Implement xattr for overlayfs.Ayush Ranjan
PiperOrigin-RevId: 329825497
2020-09-02Merge release-20200818.0-113-g0ca0d8e01 (automated)gVisor bot
2020-09-02[vfs] Fix error handling in overlayfs OpenAt.Ayush Ranjan
Updates #1199 PiperOrigin-RevId: 329802274
2020-09-02Merge release-20200818.0-112-g5c6601120 (automated)gVisor bot
2020-09-02Update Go version constraint on sync/spin_unsafe.go.Jamie Liu
PiperOrigin-RevId: 329801584
2020-09-02Merge release-20200818.0-111-g9bd016423 (automated)gVisor bot
2020-09-02Improve sync.SeqCount performance.Jamie Liu
- Make sync.SeqCountEpoch not a struct. This allows sync.SeqCount.BeginRead() to be inlined. - Mark sync.SeqAtomicLoad<T> nosplit to mitigate the Go compiler's refusal to inline it. (Best I could get was "cost 92 exceeds budget 80".) - Use runtime-guided spinning in SeqCount.BeginRead(). Benchmarks: name old time/op new time/op delta pkg:pkg/sync/sync goos:linux goarch:amd64 SeqCountWriteUncontended-12 8.24ns ± 0% 11.40ns ± 0% +38.35% (p=0.000 n=10+10) SeqCountReadUncontended-12 0.33ns ± 0% 0.14ns ± 3% -57.77% (p=0.000 n=7+8) pkg:pkg/sync/seqatomictest/seqatomic goos:linux goarch:amd64 SeqAtomicLoadIntUncontended-12 0.64ns ± 1% 0.41ns ± 1% -36.40% (p=0.000 n=10+8) SeqAtomicTryLoadIntUncontended-12 0.18ns ± 4% 0.18ns ± 1% ~ (p=0.206 n=10+8) AtomicValueLoadIntUncontended-12 0.27ns ± 3% 0.27ns ± 0% -1.77% (p=0.000 n=10+8) (atomic.Value.Load is, of course, inlined. We would expect an uncontended inline SeqAtomicLoad<int> to perform identically to SeqAtomicTryLoad<int>.) The "regression" in BenchmarkSeqCountWriteUncontended, despite this CL changing nothing in that path, is attributed to microarchitectural subtlety; the benchmark loop is unchanged except for its address: Before this CL: :0 0x4e62d1 48ffc2 INCQ DX :0 0x4e62d4 48399110010000 CMPQ DX, 0x110(CX) :0 0x4e62db 7e26 JLE 0x4e6303 :0 0x4e62dd 90 NOPL :0 0x4e62de bb01000000 MOVL $0x1, BX :0 0x4e62e3 f00fc118 LOCK XADDL BX, 0(AX) :0 0x4e62e7 ffc3 INCL BX :0 0x4e62e9 0fbae300 BTL $0x0, BX :0 0x4e62ed 733a JAE 0x4e6329 :0 0x4e62ef 90 NOPL :0 0x4e62f0 bb01000000 MOVL $0x1, BX :0 0x4e62f5 f00fc118 LOCK XADDL BX, 0(AX) :0 0x4e62f9 ffc3 INCL BX :0 0x4e62fb 0fbae300 BTL $0x0, BX :0 0x4e62ff 73d0 JAE 0x4e62d1 After this CL: :0 0x4e6361 48ffc2 INCQ DX :0 0x4e6364 48399110010000 CMPQ DX, 0x110(CX) :0 0x4e636b 7e26 JLE 0x4e6393 :0 0x4e636d 90 NOPL :0 0x4e636e bb01000000 MOVL $0x1, BX :0 0x4e6373 f00fc118 LOCK XADDL BX, 0(AX) :0 0x4e6377 ffc3 INCL BX :0 0x4e6379 0fbae300 BTL $0x0, BX :0 0x4e637d 733a JAE 0x4e63b9 :0 0x4e637f 90 NOPL :0 0x4e6380 bb01000000 MOVL $0x1, BX :0 0x4e6385 f00fc118 LOCK XADDL BX, 0(AX) :0 0x4e6389 ffc3 INCL BX :0 0x4e638b 0fbae300 BTL $0x0, BX :0 0x4e638f 73d0 JAE 0x4e6361 PiperOrigin-RevId: 329754148
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-105-g37a217aca (automated)gVisor bot
2020-09-01Implement setattr+clunk in 9PFabricio Voznika
This is to cover the common pattern: open->read/write->close, where SetAttr needs to be called to update atime/mtime before the file is closed. Benchmark results: BM_OpenReadClose/10240 CPU setattr+clunk: 63783 ns VFS2: 68109 ns VFS1: 72507 ns Updates #1198 PiperOrigin-RevId: 329628461
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-01Refactor tty codebase to use master-replica terminology.Ayush Ranjan
Updates #2972 PiperOrigin-RevId: 329584905
2020-09-01Merge release-20200818.0-101-g04c284f8c (automated)gVisor bot
2020-09-01Fix panic when calling dup2().Nayana Bidari
PiperOrigin-RevId: 329572337
2020-09-01Merge release-20200818.0-100-g723fb5c11 (automated)gVisor bot
2020-09-01[go-marshal] Enable auto-marshalling for fs/tty.Ayush Ranjan
PiperOrigin-RevId: 329564614
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-31Don't use read-only host FD for writable gofer dentries in VFS2.Jamie Liu
As documented for gofer.dentry.hostFD. PiperOrigin-RevId: 329372319
2020-08-31Merge release-20200818.0-92-g9d0d82088 (automated)gVisor bot
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 19:36:16 +0000