- 19 May, 2016 12 commits
-
-
Austin Clements authored
Currently it's possible for user code to exploit the high scheduler priority of the GC worker in conjunction with the runnext optimization to elevate a user goroutine to high priority so it will always run even if there are other runnable goroutines. For example, if a goroutine is in a tight allocation loop, the following can happen: 1. Goroutine 1 allocates, triggering a GC. 2. G 1 attempts an assist, but fails and blocks. 3. The scheduler runs the GC worker, since it is high priority. Note that this also starts a new scheduler quantum. 4. The GC worker does enough work to satisfy the assist. 5. The GC worker readies G 1, putting it in runnext. 6. GC finishes and the scheduler runs G 1 from runnext, giving it the rest of the GC worker's quantum. 7. Go to 1. Even if there are other goroutines on the run queue, they never get a chance to run in the above sequence. This requires a confluence of circumstances that make it unlikely, though not impossible, that it would happen in "real" code. In the test added by this commit, we force this confluence by setting GOMAXPROCS to 1 and GOGC to 1 so it's easy for the test to repeated trigger GC and wake from a blocked assist. We fix this by making GC always put user goroutines at the end of the run queue, instead of in runnext. This makes it so user code can't piggy-back on the GC's high priority to make a user goroutine act like it has high priority. The only other situation where GC wakes user goroutines is waking all blocked assists at the end, but this uses the global run queue and hence doesn't have this problem. Fixes #15706. Change-Id: I1589dee4b7b7d0c9c8575ed3472226084dfce8bc Reviewed-on: https://go-review.googlesource.com/23172Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently ready always puts the readied goroutine in runnext. We're going to have to change this for some uses, so add a flag for whether or not to use runnext. For now we always pass true so this is a no-op change. For #15706. Change-Id: Iaa66d8355ccfe4bbe347570cc1b1878c70fa25df Reviewed-on: https://go-review.googlesource.com/23171 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
When the generated stub functions write back the results to the stack, they can in some cases be writing to the same memory on the g0 stack. There is no race here (assuming there is no race in the Go code), but the thread sanitizer does not know that. Turn off the thread sanitizer for the stub functions to prevent false positive warnings. Current clang suggests the no_sanitize("thread") attribute, but that does not work with clang 3.6 or GCC. clang 3.6, GCC, and current clang all support the no_sanitize_thread attribute, so use that unconditionally. The test case and first version of the patch are from Dmitriy Vyukov. Change-Id: I80ce92824c6c8cf88ea0fe44f21cf50cf62474c9 Reviewed-on: https://go-review.googlesource.com/23252 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Joel Sing authored
OpenBSD 6.0 (due out November 2016) will support PT_TLS, which will allow for the OpenBSD cgo pthread_create() workaround to be removed. However, in order for Go to continue working on supported OpenBSD releases (the current release and the previous release - 5.9 and 6.0, once 6.0 is released), we cannot enable PT_TLS immediately. Instead, adjust the existing code so that it works with the previous TCB allocation and the new TIB allocation. This allows the same Go runtime to work on 5.8, 5.9 and later 6.0. Once OpenBSD 5.9 is no longer supported (May 2017, when 6.1 is released), PT_TLS can be enabled and the additional cgo runtime code removed. Change-Id: I3eed5ec593d80eea78c6656cb12557004b2c0c9a Reviewed-on: https://go-review.googlesource.com/23197Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Joel Sing <joel@sing.id.au> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
They get rewritten to NEWs, and they must be marked as escaping so walk doesn't try to allocate them back onto the stack. Fixes #15733 Change-Id: I433033e737c3de51a9e83a5a273168dbc9110b74 Reviewed-on: https://go-review.googlesource.com/23223 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Mikio Hara authored
Fixes #15316. Fixes #15574. Change-Id: I3ec8bffd35b9e5123de4be983a53fc0b8c2a0895 Reviewed-on: https://go-review.googlesource.com/23242 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Mikio Hara authored
Fixes #14717. Updates #15157. Change-Id: I7238b4fe39f3670c2dfe09b3a3df51a982f261ed Reviewed-on: https://go-review.googlesource.com/23244 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
The test case in #15639 somehow causes an invalid syscall frame. The failure is obscured because the throw occurs when throwsplit == true, which causes a "stack split at bad time" error when trying to print the throw message. This CL fixes the "stack split at bad time" by using systemstack. No test because there shouldn't be any way to trigger this error anyhow. Update #15639. Change-Id: I4240f3fd01bdc3c112f3ffd1316b68504222d9e1 Reviewed-on: https://go-review.googlesource.com/23153 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Scott Bell authored
Fixes #15088. Change-Id: I7727829a4062e15c0e5e3beff4d0bfc1fa327b0f Reviewed-on: https://go-review.googlesource.com/23232Reviewed-by:
Andrew Gerrand <adg@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Updates x/net/http2 to git rev 5916dcb1 for: * http2, lex/httplex: make Transport reject bogus headers before sending https://golang.org/cl/23229 * http2: reject more trailer values https://golang.org/cl/23230 Fixes #14048 Fixes #14188 Change-Id: Iaa8beca6e005267a3e849a10013eb424a882f2bb Reviewed-on: https://go-review.googlesource.com/23234Reviewed-by:
-
Mikio Hara authored
Updates #15735. Fixes #15741. Change-Id: Ic4ad7e948e8c3ab5feffef89d7a37417f82722a1 Reviewed-on: https://go-review.googlesource.com/23199 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Updates #15735 Change-Id: I42ab2345443bbaeaf935d683460fc2c941b7679c Reviewed-on: https://go-review.googlesource.com/23227Reviewed-by:
-
- 18 May, 2016 28 commits
-
-
Ian Lance Taylor authored
Change-Id: I54ed7a26a753afb2d6a72080e1f50ce9fba7c183 Reviewed-on: https://go-review.googlesource.com/23228 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Fixes #14508. Change-Id: I237d0c5a79a73e6c97bdb2077d8ede613128b978 Reviewed-on: https://go-review.googlesource.com/23224 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Benjamin authored
Instead, decline the session and do a full handshake. The semantics of cross-version resume are unclear, and all major client implementations treat this as a fatal error. (This doesn't come up very much, mostly if the client does the browser version fallback without sharding the session cache.) See BoringSSL's bdf5e72f50e25f0e45e825c156168766d8442dde and OpenSSL's 9e189b9dc10786c755919e6792e923c584c918a1. Change-Id: I51ca95ac1691870dd0c148fd967739e2d4f58824 Reviewed-on: https://go-review.googlesource.com/21152Reviewed-by:
Adam Langley <agl@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates x/net/http2 to golang.org/cl/23220 (http2: with Go 1.7 set Request.Context in ServeHTTP handlers) Fixes #15134 Change-Id: I73bac2601118614528f051e85dab51dc48e74f41 Reviewed-on: https://go-review.googlesource.com/23221 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Make the temporary, conservative restrictions from rev 79d9f48c in Go 1.6 permanent, and also don't do automatic TLS if the user configured a Dial or DialTLS hook. (Go 1.7 has Transport.Dialer instead, for tweaking dialing parameters) Fixes #14275 Change-Id: I5550d5c1e3a293e103eb4251a3685dc204a23941 Reviewed-on: https://go-review.googlesource.com/23222Reviewed-by:
-
Ian Lance Taylor authored
Update #13347. Change-Id: I04bf317ed409478a859355f833d4a5e30db2b9c9 Reviewed-on: https://go-review.googlesource.com/23226Reviewed-by:
-
Keith Randall authored
Run live vars test only on ssa builds. We can't just drop KeepAlive ops during regalloc. We need to replace them with copies. Change-Id: Ib4b3b1381415db88fdc2165fc0a9541b73ad9759 Reviewed-on: https://go-review.googlesource.com/23225 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Ian Lance Taylor authored
Fixes #13347. Change-Id: I591a80a1566ce70efb5f68e3ad69e7e3ab98cd9b Reviewed-on: https://go-review.googlesource.com/23102Reviewed-by:
-
Keith Randall authored
Introduce a KeepAlive op which makes sure that its argument is kept live until the KeepAlive. Use KeepAlive to mark pointer input arguments as live after each function call and at each return. We do this change only for pointer arguments. Those are the critical ones to handle because they might have finalizers. Doing compound arguments (slices, structs, ...) is more complicated because we would need to track field liveness individually (we do that for auto variables now, but inputs requires extra trickery). Turn off the automatic marking of args as live. That way, when args are explicitly nulled, plive will know that the original argument is dead. The KeepAlive op will be the eventual implementation of runtime.KeepAlive. Fixes #15277 Change-Id: I5f223e65d99c9f8342c03fbb1512c4d363e903e5 Reviewed-on: https://go-review.googlesource.com/22365Reviewed-by:
Russ Cox <rsc@golang.org>
-
Andrew Gerrand authored
Fixes #15399 Change-Id: I5b9645cb9ddede6981ce0a005e0c6fdd8a751c6f Reviewed-on: https://go-review.googlesource.com/22824Reviewed-by:
Minux Ma <minux@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Fixes #10069 Change-Id: I3819ff597d5a0c8e785403bf9d65a054f50655a6 Reviewed-on: https://go-review.googlesource.com/23207Reviewed-by:
-
Brad Fitzpatrick authored
Updates x/net/http2/hpack to rev 6050c111 for: http2/hpack: forbid excess and invalid padding in hpack decoder https://golang.org/cl/23067 Updates #15614 Change-Id: I3fbf9b265bfa5e49e6aa97d8c34e08214cfcc49a Reviewed-on: https://go-review.googlesource.com/23208Reviewed-by:
Carl Mastrangelo <notcarl@google.com> Reviewed-by:
-
Brad Fitzpatrick authored
Updates x/net/http2 to 3b99394 for golang.org/cl/23205 And associated tests. Fixes #12580 Change-Id: I1f4b59267b453d241f2afaa315b7fe10d477e52d Reviewed-on: https://go-review.googlesource.com/23206Reviewed-by:
-
Brad Fitzpatrick authored
In https://golang.org/3210, Transport errors occurring before receiving response headers were wrapped in another error type to indicate to the retry logic elsewhere that the request might be re-tryable. But a check for err == io.EOF was missed, which then became false once io.EOF was wrapped in the beforeRespHeaderError type. The beforeRespHeaderError was too fragile. Remove it. I tried to fix it in an earlier version of this CL and just broke different things instead. Also remove the "markBroken" method. It's redundant and confusing. Also, rename the checkTransportResend method to shouldRetryRequest and make it return a bool instead of an error. This also helps readability. Now the code recognizes the two main reasons we'd want to retry a request: because we never wrote the request in the first place (so: count the number of bytes we've written), or because the server hung up on us before we received response headers for an idempotent request. As an added bonus, this could make POST requests safely re-tryable since we know we haven't written anything yet. But it's too late in Go 1.7 to enable that, so we'll do that later (filed #15723). This also adds a new internal (package http) test, since testing this blackbox at higher levels in transport_test wasn't possible. Fixes #15446 Change-Id: I2c1dc03b1f1ebdf3f04eba81792bd5c4fb6b6b66 Reviewed-on: https://go-review.googlesource.com/23160Reviewed-by:
-
Ilya Tocar authored
Similar to crc32 slicing by 8. This also fixes a Crc64KB benchmark actually using 1024 bytes. Crc64/ISO64KB-4 147µs ± 0% 37µs ± 0% -75.05% (p=0.000 n=18+18) Crc64/ISO4KB-4 9.19µs ± 0% 2.33µs ± 0% -74.70% (p=0.000 n=19+20) Crc64/ISO1KB-4 2.31µs ± 0% 0.60µs ± 0% -73.81% (p=0.000 n=19+15) Crc64/ECMA64KB-4 147µs ± 0% 37µs ± 0% -75.05% (p=0.000 n=20+20) Crc64/Random64KB-4 147µs ± 0% 41µs ± 0% -72.17% (p=0.000 n=20+18) Crc64/Random16KB-4 36.7µs ± 0% 36.5µs ± 0% -0.54% (p=0.000 n=18+19) name old speed new speed delta Crc64/ISO64KB-4 446MB/s ± 0% 1788MB/s ± 0% +300.72% (p=0.000 n=18+18) Crc64/ISO4KB-4 446MB/s ± 0% 1761MB/s ± 0% +295.20% (p=0.000 n=18+20) Crc64/ISO1KB-4 444MB/s ± 0% 1694MB/s ± 0% +281.46% (p=0.000 n=19+20) Crc64/ECMA64KB-4 446MB/s ± 0% 1788MB/s ± 0% +300.77% (p=0.000 n=20+20) Crc64/Random64KB-4 446MB/s ± 0% 1603MB/s ± 0% +259.32% (p=0.000 n=20+18) Crc64/Random16KB-4 446MB/s ± 0% 448MB/s ± 0% +0.54% (p=0.000 n=18+20) Change-Id: I1c7621d836c486d6bfc41dbe1ec2ff9ab11aedfc Reviewed-on: https://go-review.googlesource.com/22222 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Lee Hinman authored
in root_cgo_darwin.go only certificates from the System Domain were being used in FetchPEMRoots. This patch adds support for getting certificates from all three domains (System, Admin, User). Also it will only read trusted certificates from those Keychains. Because it is possible to trust a non Root certificate, this patch also adds a checks to see if the Subject and Issuer name are the same. Fixes #14514 Change-Id: Ia03936d7a61d1e24e99f31c92f9927ae48b2b494 Reviewed-on: https://go-review.googlesource.com/20351Reviewed-by:
-
Adam Langley authored
The fact that crypto/ecdsa.Verify didn't reject negative inputs was a mistake on my part: I had unsigned numbers on the brain. However, it doesn't generally cause problems. (ModInverse results in zero, which results in x being zero, which is rejected.) The amd64 P-256 code will crash when given a large, negative input. This fixes both crypto/ecdsa to reject these values and also the P-256 code to ignore the sign of inputs. Change-Id: I6370ed7ca8125e53225866f55b616a4022b818f8 Reviewed-on: https://go-review.googlesource.com/22093 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Monty Taylor authored
Go is being proposed as an officially supported language for elements of OpenStack: https://review.openstack.org/#/c/312267/ As such, repos that exist in OpenStack's git infrastructure are likely to become places from which people might want to go get things. Allow optional .git suffixes to allow writing code that depends on git.openstack.org repos that will work with older go versions while we wait for this support to roll out. Change-Id: Ia64bdb1dafea33b1c3770803230d30ec1059df22 Reviewed-on: https://go-review.googlesource.com/23135Reviewed-by:
-
David Chase authored
sparseSet and sparseMap only need 32 bit integers in their arrays, since a sparseEntry key is also limited to 32 bits. This appears to reduce the space allocated for at least one pathological compilation by 1%, perhaps more. Not necessarily for 1.7, but it saves a little and is very low-risk. Change-Id: Icf1185859e9f5fe1261a206b441e02c34f7d02fd Reviewed-on: https://go-review.googlesource.com/22972 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Cuihtlauac ALVARADO authored
On some systems, gdb is set to: "startup-with-shell on". This breaks runtime_test. This just make sure gdb does not start by spawning a shell. Fixes #15354 Change-Id: Ia040931c61dea22f4fdd79665ab9f84835ecaa70 Reviewed-on: https://go-review.googlesource.com/23142Reviewed-by:
-
Matthew Dempsky authored
Previously statements like f(unsafe.Pointer(g()), int(h())) would be reordered into a sequence of statements like autotmp_g := g() autotmp_h := h() f(unsafe.Pointer(autotmp_g), int(autotmp_h)) which can leave g's temporary value on the stack as a uintptr, rather than an unsafe.Pointer. Instead, recognize uintptr-to-unsafe.Pointer conversions when reordering function calls to instead produce: autotmp_g := unsafe.Pointer(g()) autotmp_h := h() f(autotmp_g, int(autotmp_h)) Fixes #15329. Change-Id: I2cdbd89d233d0d5c94791513a9fd5fd958d11ed5 Reviewed-on: https://go-review.googlesource.com/22273 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Ian Lance Taylor authored
Fixes #14656. Change-Id: I37a9aa51705ae18bd034f2cc6dbf06a55f969197 Reviewed-on: https://go-review.googlesource.com/23202Reviewed-by:
Rob Pike <r@golang.org>
-
Mikio Hara authored
Change-Id: I7881e3353dc5cd9755a79ea0eab146c6a0a08306 Reviewed-on: https://go-review.googlesource.com/23195 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> Reviewed-by:
-
Mikio Hara authored
Looks like some version of Android still fails with "servname not supported for ai_socktype". It probably doesn't support ai_socktype=SOCK_STREAM. Updates #14576. Change-Id: I77ecff147d5b759e3281b3798c60f150a4aab811 Reviewed-on: https://go-review.googlesource.com/23194Reviewed-by:
-
Brad Fitzpatrick authored
Fixes #14793 Change-Id: I408056d096cd6a999fa5e349704b5ea8e26d2e4e Reviewed-on: https://go-review.googlesource.com/23201Reviewed-by:
-
Ian Lance Taylor authored
The signal might get delivered to a different thread, and that thread might not run again before the currently running thread returns and exits. Sleep to give the other thread time to pick up the signal and crash. Not tested for all cases, but, optimistically: Fixes #14063. Change-Id: Iff58669ac6185ad91cce85e0e86f17497a3659fd Reviewed-on: https://go-review.googlesource.com/23203 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Mikio Hara <mikioh.mikioh@gmail.com>
-
Emmanuel Odeke authored
Update the doc for CreateCertificateRequest to state that it creates a `new certificate request` instead of just a `new certificate` Fixes #14649. Change-Id: Ibbbcf91d74168998990990e78e5272a6cf294d51 Reviewed-on: https://go-review.googlesource.com/23204Reviewed-by:
-
Brad Fitzpatrick authored
Verify that for a server doing chunked encoding, with the final data and EOF arriving together, the client will reuse the connection even if it closes the body without seeing an EOF. The server sends at least one non-zero chunk and one zero chunk. This verifies that the client's bufio reading reads ahead and notes the EOF, so even if the JSON decoder doesn't read the EOF itself, as long as somebody sees it, a close won't forcible tear down the connection. This was true at least of https://golang.org/cl/21291 No code change. Test already passed (even with lots of runs, including in race mode with randomized goroutine scheduling). Updates #15703 Change-Id: I2140b3eec6b099b6b6e54f153fe271becac5d949 Reviewed-on: https://go-review.googlesource.com/23200 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
