The PROXY protocol is supported by several proxy servers such as haproxy
and Amazon ELB.  This protocol allows services running behind a proxy to
learn the remote address of the actual client connecting to the proxy,
by including a single textual line at the beginning of the TCP
connection.
http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt

There are several Go libraries for this protocol (such as
https://github.com/armon/go-proxyproto), which operate by wrapping a
net.Conn with an implementation whose RemoteAddr method reads the
protocol line before returning. This means that RemoteAddr is a blocking
call.

Before this change, http.Serve called RemoteAddr from the main Accepting
goroutine, not from the per-connection goroutine. This meant that it
would not Accept another connection until RemoteAddr returned, which is
not appropriate if RemoteAddr needs to do a blocking read from the
socket first.

Fixes #12943.

Change-Id: I1a242169e6e4aafd118b794e7c8ac45d0d573421
Reviewed-on: https://go-review.googlesource.com/15835Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I2ac6b178e666e34e028001078faf62ce71e12e9d
Reviewed-on: https://go-review.googlesource.com/15834Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Allow all CGI environment settings from the inherited set and default
inherited set to be overridden including PATH by Env.

Change-Id: Ief8d33247b879fa87a8bfd6416d4813116db98de
Reviewed-on: https://go-review.googlesource.com/14959Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

The current fastlog2 testing checks all 64M values in the domain of
interest, which is too much for platforms with no native floating point.

Reduce testing under testing.Short() to speed up builds for those platforms.

Related to #12620

Change-Id: Ie5dcd408724ba91c3b3fcf9ba0dddedb34706cd1
Reviewed-on: https://go-review.googlesource.com/15830Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Joel Sing <jsing@google.com>
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The documentation listing err == EOF can be confusing to newcomers
to the language who are looking for the relevant documentation for
that error.

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

Due to #9401, trailing empty fields will occupy at least 1 byte
of space.

Fixes #12884.

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

Also, handle the case where 'read' returns EINVAL instead of EBADF
when the descriptor is not ready. (android 4.4.4/cyanogenmod, nexus7)

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

Fixes these warnings from go vet:
buildid_linux.go:25: no formatting directive in Fatalf call
callback.go:180: arg pc[i] for printf verb %p of wrong type: uintptr
env.go:34: possible misuse of unsafe.Pointer
issue7665.go:22: possible misuse of unsafe.Pointer

Change-Id: I83811b9c10c617139713a626b4a34ab05564d4fe
Reviewed-on: https://go-review.googlesource.com/15802Reviewed-by: David Crawshaw <crawshaw@golang.org>

Fixes #12785

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

The duplication of _Kind and kind constants is a legacy of the
conversion from C.

Change-Id: I368b35a41f215cf91ac4b09dac59699edb414a0e
Reviewed-on: https://go-review.googlesource.com/15800Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

There is no easy way to understand what user intent was and whether
they wanted to use a dynamic import or not.

If we skip logging such errors, it breaks common use cases such as
https://golang.org/issue/12810.

It's a better approach to expose the underlying mechanism and
be more verbose with the error messages.

Fixes #12810.

Change-Id: I7e922c9e848382690d9d9b006d7046e6cf93223b
Reviewed-on: https://go-review.googlesource.com/15756Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #12907.

Change-Id: I5925852fe6962d4ec7dbb3ea5323e8ddfaf9d576
Reviewed-on: https://go-review.googlesource.com/15755Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I536d55f784bb042a2dee94b2878aff42bc182eed
Reviewed-on: https://go-review.googlesource.com/15734Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

These were proposed in the RFC over three years ago, then proposed to
be added to Go in https://codereview.appspot.com/7678043/ 2 years and
7 months ago, and the spec hasn't been updated or retracted the whole
time.

Time to export them.

Of note, HTTP/2 uses code 431 (Request Header Fields Too Large).

Updates #12843

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

A MIME header can include values defined on several lines.
Only the first line of each value was trimmed.

Make sure all the lines are trimmed before being aggregated.

Fixes #11204

Change-Id: Id92f384044bc6c4ca836e5dba2081fe82c82dc85
Reviewed-on: https://go-review.googlesource.com/15683Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #12722

Change-Id: I6a630d8b072ef2b1c63de941743148f8c96b8e5f
Reviewed-on: https://go-review.googlesource.com/15671Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #12674

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

Change-Id: I34c8ada1f3c5d401944483df424011fa2ae9fc3d
Reviewed-on: https://go-review.googlesource.com/15673Reviewed-by: Dave Cheney <dave@cheney.net>

Fixes #12866

net/http.Client returns some errors wrapped in a *url.Error. To avoid
the requirement to unwrap these errors to determine if the cause was
temporary or a timeout, make *url.Error implement net.Error directly.

Change-Id: I1ba84ecc7ad5147a40f056ff1254e60290152408
Reviewed-on: https://go-review.googlesource.com/15672Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

A vast majority of the time, ReadError isn't even returned during
IO operations. Instead, an unwrapped error will be returned because
of the ReadByte call on L705. Because DEFLATE streams are primarily
compressed and require byte for byte Huffman decoding, most of the
data read from a data stream will go through ReadByte.

Although this is technically an API change, any user reliant on
this error would not have worked properly anyways due to the fact
that most IO error are not wrapped. We might as well deprecate
ReadError. It is useless and actually makes clients that do
depend on catching IO errors more difficult.

Fixes #11856
Fixes #12724

Change-Id: Ib5fec5ae215e977c4e85de5701ce6a473d400af8
Reviewed-on: https://go-review.googlesource.com/14834Reviewed-by: Nigel Tao <nigeltao@golang.org>

The -W option has not worked since Go 1.3.  It is not documented.  When
it did work, it generated useful output, but it was for human viewing;
there was no reason to write a script that passes the -W option, so it's
unlikely that anybody is using it today.

Change-Id: I4769f1ffd308a48324a866592eb7fd79a4cdee54
Reviewed-on: https://go-review.googlesource.com/15701Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Remove another use of NodeList.

Change-Id: Ice07eff862caf715f722dec7829006bf71715b07
Reviewed-on: https://go-review.googlesource.com/15432Reviewed-by: Dave Cheney <dave@cheney.net>

All warnings in cmd/go are printed using fmt.Fprintf(os.Stderr...)
except one in test.go which is printed using log.Printf.
This is a minor inconsistency.

Change-Id: Ib470d318810b44b86e6cfaa77e9a556a5ad94069
Reviewed-on: https://go-review.googlesource.com/15657
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Currently, when the mutator allocates, the runtime first allocates the
memory and then, if that G has done "enough" allocation, the runtime
checks whether the G has assist debt to pay off and, if so, pays it
off. This approach leads to under-assisting, where a G can allocate a
large region (or many small regions) before paying for it, or can even
exit with outstanding debt.

This commit flips this around so that a G always acquires enough
credit for an allocation before it can perform that allocation. We
continue to amortize the cost of assists by requiring that they
over-assist when triggered to build up credit for many allocations.

Fixes #11967.

Change-Id: Idac9f11133b328535667674d837be72c23ebd899
Reviewed-on: https://go-review.googlesource.com/15409Reviewed-by: Rick Hudson <rlh@golang.org>
Run-TryBot: Austin Clements <austin@google.com>

Currently we track the per-G GC assist balance as two monotonically
increasing values: the bytes allocated by the G this cycle (gcalloc)
and the scan work performed by the G this cycle (gcscanwork). The
assist balance is hence assistRatio*gcalloc - gcscanwork.

This works, but has two important downsides:

1) It requires floating-point math to figure out if a G is in debt or
   not. This makes it inappropriate to check for assist debt in the
   hot path of mallocgc, so we only do this when a G allocates a new
   span. As a result, Gs can operate "in the red", leading to
   under-assist and extended GC cycle length.

2) Revising the assist ratio during a GC cycle can lead to an "assist
   burst". If you think of plotting the scan work performed versus
   heaps size, the assist ratio controls the slope of this line.
   However, in the current system, the target line always passes
   through 0 at the heap size that triggered GC, so if the runtime
   increases the assist ratio, there has to be a potentially large
   assist to jump from the current amount of scan work up to the new
   target scan work for the current heap size.

This commit replaces this approach with directly tracking the GC
assist balance in terms of allocation credit bytes. Allocating N bytes
simply decreases this by N and assisting raises it by the amount of
scan work performed divided by the assist ratio (to get back to
bytes).

This will make it cheap to figure out if a G is in debt, which will
let us efficiently check if an assist is necessary *before* performing
an allocation and hence keep Gs "in the black".

This also fixes assist bursts because the assist ratio is now in terms
of *remaining* work, rather than work from the beginning of the GC
cycle. Hence, the plot of scan work versus heap size becomes
continuous: we can revise the slope, but this slope always starts from
where we are right now, rather than where we were at the beginning of
the cycle.

Change-Id: Ia821c5f07f8a433e8da7f195b52adfedd58bdf2c
Reviewed-on: https://go-review.googlesource.com/15408Reviewed-by: Rick Hudson <rlh@golang.org>

Currently we ensure a minimum heap distance of 1MB when computing the
assist ratio. Rather than enforcing this minimum on the heap distance,
it makes more sense to enforce that the heap goal itself is at least
1MB over the live heap size at the beginning of GC. Currently the two
approaches are semantically equivalent, but this will let us switch to
basing the assist ratio on current heap distance rather than the
initial heap distance, since we can't enforce this minimum on the
current heap distance (the GC may never finish because the goal posts
will always be 1MB away).

Change-Id: I0027b1c26a41a0152b01e5b67bdb1140d43ee903
Reviewed-on: https://go-review.googlesource.com/15604Reviewed-by: Rick Hudson <rlh@golang.org>

Currently, gcController.scanWork is updated as lazily as possible
since it is only read at the end of the GC cycle. We're about to read
it during the GC cycle to improve the assist ratio revisions, so
modify gcDrain* to regularly flush to gcController.scanWork in much
the same way as we regularly flush to gcController.bgScanCredit.

One consequence of this is that it's difficult to keep gcw.scanWork
monotonic, so we give up on that and simply return the amount of scan
work done by gcDrainN rather than calculating it in the caller.

Change-Id: I7b50acdc39602f843eed0b5c6d2dacd7e762b81d
Reviewed-on: https://go-review.googlesource.com/15407Reviewed-by: Rick Hudson <rlh@golang.org>

Currently callers of gcDrain control whether it flushes scan work
credit to gcController.bgScanCredit by passing a value other than -1
for the flush threshold. Shortly we're going to make this always flush
scan work to gcController.scanWork and optionally also flush scan work
to gcController.bgScanCredit. This will be much easier if the flush
threshold is simply a constant (which it is in practice) and callers
merely control whether or not the flush includes the background
credit. Hence, replace the flush threshold argument with a flag.

Change-Id: Ia27db17de8a3f1e462a5d7137d4b5dc72f99a04e
Reviewed-on: https://go-review.googlesource.com/15406Reviewed-by: Rick Hudson <rlh@golang.org>

These functions were nearly identical. Consolidate them by adding a
flags argument. In addition to cleaning up this code, this makes
further changes that affect both functions easier.

Change-Id: I6ec5c947603bbbd3ff4040113b2fbc240e99745f
Reviewed-on: https://go-review.googlesource.com/15405Reviewed-by: Rick Hudson <rlh@golang.org>

Change-Id: I950af8d80433b3ae8a1da0aa7a8d2d0b295dd313
Reviewed-on: https://go-review.googlesource.com/15404Reviewed-by: Rick Hudson <rlh@golang.org>

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

The comment for assistRatio claimed it to be the reciprocal of what it
actually is.

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

  (*T)(unsafe.Pointer(&t)) === &t
for t of type T

Change-Id: I43c1aa436747dfa0bf4cb0d615da1647633f9536
Reviewed-on: https://go-review.googlesource.com/15656Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #12867

Change-Id: I8ba81c622bce2a77a6142f941603198582eaf8a4
Reviewed-on: https://go-review.googlesource.com/15570Reviewed-by: Robert Griesemer <gri@golang.org>

The case fixed by this change happens when, in func (pr partReader)
Read, the Peek happens to read so that peek looks like:

  "somedata\r\n--Boundary\r"

peekBufferSeparatorIndex was returning (-1, false) because it didn't
find the trailing '\n'.

This was wrong because:

1) It didn't match the documentation: as "\r\n--Boundary" was found, it
should return the index of that pattern, not -1.

2) It lead to an nCopy cut such as:
  "somedata\r| |\n--Boundary\r" instead of "somedata| |\r\n--Boundary\r"
which made the subsequent Read miss the boundary, and eventually end
with a "return 0, io.ErrUnexpectedEOF" case, as reported in:

https://github.com/camlistore/camlistore/issues/642

Change-Id: I1ba78a741bc0c7719e160add9cca932d10f8a615
Reviewed-on: https://go-review.googlesource.com/15269Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I51edc77ad4621ad8f3908e69dcb7b4eab086b5fe
Reviewed-on: https://go-review.googlesource.com/15680Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #10342

Change-Id: I69c69352016a8fd0b62541128c2e86b242ebbe26
Reviewed-on: https://go-review.googlesource.com/15630Reviewed-by: Minux Ma <minux@golang.org>

obj.ProgInfo is a field inside obj.Prog, which is currently 320 bytes
on 64bit platforms. By moving the Flags field below the other fields
the size of obj.Prog drops into the 288 byte size class, a saving of
32 bytes per value allocated on the heap.

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

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

Go shared libraries do not support dlclose, and there is no likelihood
that they will suppose dlclose in the future.  Set the DF_1_NODELETE
flag to tell the dynamic linker to not attempt to remove them from
memory.  This makes the shared library act as though every call to
dlopen passed the RTLD_NODELETE flag.

Fixes #12582.
Update #11100.
Update #12873.

Change-Id: Id4b6e90a1b54e2e6fc8355b5fb22c5978fc762b4
Reviewed-on: https://go-review.googlesource.com/15605Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>