commit fa6752a5370735b8c2404d6de5191f2eea67130f [browse]
Author: Carlos Amedee
Date: 2021-02-04 11:17:11 -05:00

[release-branch.go1.15] go1.15.8

Change-Id: Ic8824cabbc8ae62360e0cda4b7c5604db7d405f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/289694
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Trust: Carlos Amedee <carlos@golang.org>

commit c3e1c3800bfb56bf1b0c3d696f59f42b16bd4fc2 [browse]
Author: Elias Naur
Date: 2020-12-25 11:14:11 +01:00

[release-branch.go1.15] runtime/cgo: fix Android build with NDK 22

Fixes #43406

Change-Id: I7d2b70098a4ba4dcb325fb0be076043789b86135
Reviewed-on: https://go-review.googlesource.com/c/go/+/280312
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Elias Naur <mail@eliasnaur.com>
(cherry picked from commit 1d78139128d6d839d7da0aeb10b3e51b6c7c0749)
Reviewed-on: https://go-review.googlesource.com/c/go/+/289149

commit 3171f483775c7eb8d38b68f53d8fd5078db7f967 [browse]
Author: Ian Lance Taylor
Date: 2021-01-19 21:30:36 -08:00

[release-branch.go1.15] runtime: don't adjust timer pp field in timerWaiting status

Before this CL, the following sequence was possible:

* GC scavenger starts and sets up scavenge.timer
* GC calls readyForScavenger, but sysmon is sleeping
* program calls runtime.GOMAXPROCS to shrink number of processors
* procresize destroys a P, the one that scavenge.timer is on
* (*pp).destroy calls moveTimers, which gets to the scavenger timer
* scavenger timer is timerWaiting, and moveTimers clears t.pp
* sysmon wakes up and calls wakeScavenger
* wakeScavengers calls stopTimer on scavenger.timer, still timerWaiting
* stopTimer calls deltimer which loads t.pp, which is still nil
* stopTimer tries to increment deletedTimers on nil t.pp, and crashes

The point of vulnerability is the time that t.pp is set to nil by
moveTimers and the time that t.pp is set to non-nil by moveTimers,
which is a few instructions at most. So it's not likely and in
particular is quite unlikely on x86. But with a more relaxed memory
model the area of vulnerability can be somewhat larger. This appears
to tbe the cause of two builder failures in a few months on linux-mips.

This CL fixes the problem by making moveTimers change the status from
timerWaiting to timerMoving while t.pp is clear. That will cause
deltimer to wait until the status is back to timerWaiting, at which
point t.pp has been set again.

For #43712
Fixes #43833

Change-Id: I66838319ecfbf15be66c1fac88d9bd40e2295852
Reviewed-on: https://go-review.googlesource.com/c/go/+/284775
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit d2d155d1ae8c704a37f42fd3ebb1f3846f78e4d4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/287092
Run-TryBot: Carlos Amedee <carlos@golang.org>

commit 58dc4452620ebefa75742661c538b8406b213b4a [browse]
Author: Than McIntosh
Date: 2020-12-15 15:54:25 -05:00

[release-branch.go1.15] cmd/internal/goobj2: fix buglet in object file reader

The code in the Go object file reader was casting a pointer to mmaped
memory into a large array prior to performing a read of the
relocations section:

	return (*[1<<20]Reloc)(unsafe.Pointer(&r.b[off]))[:n:n]

For very large object files, this artificial array isn't large enough
(that is, there are more than 1048576 relocs to read), so update the
code to use a larger artifical array size.

Fixes #43214.
Updates #41621.

Change-Id: Ic047c8aef4f8a3839f2e7e3594bce652ebd6bd5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278492
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Than McIntosh <thanm@google.com>
(cherry picked from commit f4e7a6b905ce60448e506a3f6578d01b60602cdd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/278673

commit aa9b48cd1837644a1555fd7a370800924cef627a [browse]
Author: Derek Parker
Date: 2020-11-25 16:31:57 Z

[release-branch.go1.15] cmd/link/internal/ld/pe: fix segfault adding resource section

The resource symbol may have been copied to the mmap'd
output buffer. If so, certain conditions can cause that
mmap'd output buffer to be munmap'd before we get a chance
to use it. To avoid any issues we copy the data to the heap
when the resource symbol exists.

Fixes #42384

Change-Id: I32ef5420802d7313a3d965b8badfbcfb9f0fba4a
GitHub-Last-Rev: 7b0f43011d06083ee3e871e48a87847636f738f9
GitHub-Pull-Request: golang/go#42427
Reviewed-on: https://go-review.googlesource.com/c/go/+/268018
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Carlos Amedee <carlos@golang.org>