Fixes #15673

Change-Id: Ib36d8db3299a93d92665dbde012d52c2c5332ac0
Reviewed-on: https://go-review.googlesource.com/23253Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates x/net/http2 to git rev 8a52c78 for golang.org/cl/23258
(http2: fix Transport.CloseIdleConnections when http1+http2 are wired together)

Fixes #14607

Change-Id: I038badc69e230715b8ce4e398eb5e6ede73af918
Reviewed-on: https://go-review.googlesource.com/23280Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Iedce3770a92112802f3a45c7b95ee145ab5b187e
Reviewed-on: https://go-review.googlesource.com/23282Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

Updates x/net/http2 to git rev 202ff482 for https://golang.org/cl/23235 (Expect:
100-continue support for HTTP/2)

Fixes a flaky test too, and changes the automatic HTTP/2 behavior to
no longer special-case the DefaultTransport, because
ExpectContinueTimeout is no longer unsupported by the HTTP/2
transport.

Fixes #13851
Fixes #15744

Change-Id: I3522aace14179a1ca070fd7063368a831167a0f7
Reviewed-on: https://go-review.googlesource.com/23254Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #15745.

Change-Id: I6f9a1dcf0b1d97cb443900c7d8da09ead83d4b6a
Reviewed-on: https://go-review.googlesource.com/23243
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This patch adds Unshare flags to SysProcAttr for Linux systems.

Fixes #1954

Change-Id: Id819c3f92b1474e5a06dd8d55f89d74a43eb770c
Reviewed-on: https://go-review.googlesource.com/23233
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Non-syntax errors are always counted to determine if to exit
early, but then deduplication eliminates them. This can lead
to situations which report "too many errors" and only one
error is shown.

De-duplicate non-syntax errors early, at least the ones that
appear consecutively, and only count the ones actually being
shown. This doesn't work perfectly as they may not appear in
sequence, but it's cheap and good enough.

Fixes #14136.

Change-Id: I7b11ebb2e1e082f0d604b88e544fe5ba967af1d7
Reviewed-on: https://go-review.googlesource.com/23259Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Fixes #14238

Change-Id: I1538bfb5cfa63e36a89df1f6eb9f5a0dcafb6ce5
Reviewed-on: https://go-review.googlesource.com/23256Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

In Go versions 1 up to and including Go 1.6,
ResponseRecorder.HeaderMap was both the map that handlers got access
to, and was the map tests checked their results against. That did not
mimic the behavior of the real HTTP server (Issue #8857), so HeaderMap
was changed to be a snapshot at the first write in
https://golang.org/cl/20047. But that broke cases where the Handler
never did a write (#15560), so revert the behavior.

Instead, introduce the ResponseWriter.Result method, returning an
*http.Response. It subsumes ResponseWriter.Trailers which was added
for Go 1.7 in CL 20047. Result().Header now contains the correct
answer, and HeaderMap is unchanged in behavior from previous Go
releases, so we don't break people's tests. People wanting the correct
behavior can use ResponseWriter.Result.

Fixes #15560
Updates #8857

Change-Id: I7ea9b56a6b843103784553d67f67847b5315b3d2
Reviewed-on: https://go-review.googlesource.com/23257Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #14340

Change-Id: I43e1624fafc972fb868708c3857fc8acf1bfbbd7
Reviewed-on: https://go-review.googlesource.com/23255
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

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>

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: Rick Hudson <rlh@golang.org>

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>

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>

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>

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>

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: Brad Fitzpatrick <bradfitz@golang.org>

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>

Fixes #15088.

Change-Id: I7727829a4062e15c0e5e3beff4d0bfc1fa327b0f
Reviewed-on: https://go-review.googlesource.com/23232Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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 <bradfitz@golang.org>

Updates #15735

Change-Id: I42ab2345443bbaeaf935d683460fc2c941b7679c
Reviewed-on: https://go-review.googlesource.com/23227Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I54ed7a26a753afb2d6a72080e1f50ce9fba7c183
Reviewed-on: https://go-review.googlesource.com/23228
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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: Austin Clements <austin@google.com>

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>

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: Andrew Gerrand <adg@golang.org>

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: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Update #13347.

Change-Id: I04bf317ed409478a859355f833d4a5e30db2b9c9
Reviewed-on: https://go-review.googlesource.com/23226Reviewed-by: Ian Lance Taylor <iant@golang.org>

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>

Fixes #13347.

Change-Id: I591a80a1566ce70efb5f68e3ad69e7e3ab98cd9b
Reviewed-on: https://go-review.googlesource.com/23102Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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: David Chase <drchase@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #15399

Change-Id: I5b9645cb9ddede6981ce0a005e0c6fdd8a751c6f
Reviewed-on: https://go-review.googlesource.com/22824Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #10069

Change-Id: I3819ff597d5a0c8e785403bf9d65a054f50655a6
Reviewed-on: https://go-review.googlesource.com/23207Reviewed-by: Russ Cox <rsc@golang.org>

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 <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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: Russ Cox <rsc@golang.org>

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: Russ Cox <rsc@golang.org>

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: Brad Fitzpatrick <bradfitz@golang.org>

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: Russ Cox <rsc@golang.org>