Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/golang/go. Pull mirroring updated .
  1. Apr 01, 2021
  2. Mar 31, 2021
  3. Mar 30, 2021
  4. Mar 29, 2021
  5. Mar 25, 2021
    • Cherry Zhang's avatar
      [release-branch.go1.15] cmd/link: generate trampoline for inter-dependent packages · 7c88ae41
      Cherry Zhang authored
      Currently, in the trampoline generation pass we expect packages
      are laid out in dependency order, so a cross-package jump always
      has a known target address so we can check if a trampoline is
      needed. With linknames, there can be cycles in the package
      dependency graph, making this algorithm no longer work. For them,
      as the target address is unkown we conservatively generate a
      trampoline. This may generate unnecessary trampolines (if the
      packages turn out laid together), but package cycles are extremely
      rare so this is fine.
      
      Updates #44639.
      Fixes #44748.
      
      Change-Id: I2dc2998edacbda27d726fc79452313a21d07787a
      Reviewed-on: https://go-review.googlesource.com/c/go/+/292490
      
      
      Trust: Cherry Zhang <cherryyz@google.com>
      Reviewed-by: default avatarThan McIntosh <thanm@google.com>
      (cherry picked from commit 098504c7)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/298030
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Go Bot <gobot@golang.org>
      7c88ae41
    • Jay Conrod's avatar
      [release-branch.go1.15] cmd/go/internal/modfetch: detect and recover from missing ziphash file · 7038a380
      Jay Conrod authored
      Previously, if an extracted module directory existed in the module
      cache, but the corresponding ziphash file did not, if the sum was
      missing from go.sum, we would not verify the sum. This caused 'go get'
      not to write missing sums. 'go build' in readonly mode (now the
      default) checks for missing sums and doesn't attempt to fetch modules
      that can't be verified against go.sum.
      
      With this change, when requesting the module directory with
      modfetch.DownloadDir, if the ziphash file is missing, the go command
      will re-hash the zip without downloading or re-extracting it again.
      
      Note that the go command creates the ziphash file before the module
      directory, but another program could remove it separately, and it
      might not be present after a crash.
      
      Fixes #44872
      
      Change-Id: I64551e048a3ba17d069de1ec123d5b8b2757543c
      Reviewed-on: https://go-review.googlesource.com/c/go/+/298352
      
      
      Trust: Jay Conrod <jayconrod@google.com>
      Run-TryBot: Jay Conrod <jayconrod@google.com>
      TryBot-Result: Go Bot <gobot@golang.org>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      (cherry picked from commit 302a4003)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/299830
      7038a380
  6. Mar 11, 2021
  7. Mar 10, 2021
  8. Mar 09, 2021
  9. Mar 02, 2021
  10. Mar 01, 2021
    • Matthew Dempsky's avatar
      [release-branch.go1.15] cmd/compile: fix escape analysis of heap-allocated results · f75ab2d5
      Matthew Dempsky authored
      One of escape analysis's responsibilities is to summarize whether/how
      each function parameter flows to the heap so we can correctly
      incorporate those flows into callers' escape analysis data flow
      graphs.
      
      As an optimization, we separately record when parameters flow to
      result parameters, so that we can more precisely analyze parameter
      flows based on how the results are used at the call site. However, if
      a named result parameter itself needs to be heap allocated, this
      optimization isn't safe and the parameter needs to be recorded as
      flowing to heap rather than flowing to result.
      
      Escape analysis used to get this correct because it conservatively
      rewalked the data-flow graph multiple times. So even though it would
      incorrectly record the result parameter flow, it would separately find
      a flow to the heap. However, CL 196811 (specifically, case 3)
      optimized the walking logic to reduce unnecessary rewalks causing us
      to stop finding the extra heap flow.
      
      This CL fixes the issue by correcting location.leakTo to be sensitive
      to sink.escapes and not record result-flows when the result parameter
      escapes to the heap.
      
      Fixes #44658.
      
      Change-Id: I48742ed35a6cab591094e2d23a439e205bd65c50
      Reviewed-on: https://go-review.googlesource.com/c/go/+/297289
      
      
      Trust: Matthew Dempsky <mdempsky@google.com>
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Go Bot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      Reviewed-on: https://go-review.googlesource.com/c/go/+/297291
      f75ab2d5
    • Ian Lance Taylor's avatar
      [release-branch.go1.15] time: correct unusual extension string cases · 6bb96000
      Ian Lance Taylor authored
      This fixes two uncommon cases.
      
      First, the tzdata code permits timezone offsets up to 24 * 7, although
      the POSIX TZ parsing does not. The tzdata code uses this to specify a
      day of week in some cases.
      
      Second, we incorrectly rejected a negative time offset for when a time
      zone change comes into effect.
      
      For #44385
      Fixes #44617
      
      Change-Id: I5f2efc1d385e9bfa974a0de3fa81e7a94b827602
      Reviewed-on: https://go-review.googlesource.com/c/go/+/296392
      
      
      Trust: Ian Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Go Bot <gobot@golang.org>
      Reviewed-by: default avatarTobias Klauser <tobias.klauser@gmail.com>
      (cherry picked from commit d9fd38e6)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/297229
      6bb96000
    • Jason A. Donenfeld's avatar
      [release-branch.go1.15] syscall: do not overflow key memory in GetQueuedCompletionStatus · 4fda89d4
      Jason A. Donenfeld authored
      The third argument to GetQueuedCompletionStatus is a pointer to a
      uintptr, not a uint32. Users of this functions have therefore been
      corrupting their memory every time they used it. Either that memory
      corruption was silent (dangerous), or their programs didn't work so they
      chose a different API to use.
      
      This fixes the problem by passing through an intermediate buffer.
      
      Updates #44538.
      Fixes #44592.
      
      Change-Id: Icacd71f705b36e41e52bd8c4d74898559a27522f
      Reviewed-on: https://go-review.googlesource.com/c/go/+/296151
      
      
      Trust: Jason A. Donenfeld <Jason@zx2c4.com>
      Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
      TryBot-Result: Go Bot <gobot@golang.org>
      Reviewed-by: default avatarBryan C. Mills <bcmills@google.com>
      4fda89d4
    • Jason A. Donenfeld's avatar
      [release-branch.go1.15] cmd/compile: do not assume TST and TEQ set V on arm · d9b4ef59
      Jason A. Donenfeld authored
      These replacement rules assume that TST and TEQ set V. But TST and
      TEQ do not set V. This is a problem because instructions like LT are
      actually checking for N!=V. But with TST and TEQ not setting V, LT
      doesn't do anything meaningful. It's possible to construct trivial
      miscompilations from this, such as:
      
          package main
      
          var x = [4]int32{-0x7fffffff, 0x7fffffff, 2, 4}
      
          func main() {
              if x[0] > x[1] {
                  panic("fail 1")
              }
              if x[2]&x[3] < 0 {
                  panic("fail 2") // Fails here
              }
          }
      
      That first comparison sets V, via the CMP that subtracts the values
      causing the overflow. Then the second comparison operation thinks that
      it uses the result of TST, when it actually uses the V from CMP.
      
      Before this fix:
      
          TST             R0, R1
          BLT             loc_6C164
      
      After this fix:
      
          TST             R0, R1
          BMI             loc_6C164
      
      The BMI instruction checks the N flag, which TST sets.  This commit
      fixes the issue by using [LG][TE]noov instead of vanilla [LG][TE], and
      also adds a test case for the direct issue.
      
      Updates #42876.
      Fixes #42930.
      
      Change-Id: I13c62c88d18574247ad002b671b38d2d0b0fc6fa
      Reviewed-on: https://go-review.googlesource.com/c/go/+/282432
      
      
      Trust: Jason A. Donenfeld <Jason@zx2c4.com>
      Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
      TryBot-Result: Go Bot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      d9b4ef59
  11. Feb 26, 2021
    • Wei Fu's avatar
      [release-branch.go1.15] internal/poll: netpollcheckerr before sendfile · 30357d6e
      Wei Fu authored
      In net/http package, the ServeContent/ServeFile doesn't check the I/O
      timeout error from chunkWriter or *net.TCPConn, which means that both
      HTTP status and headers might be missing when WriteTimeout happens. If
      the poll.SendFile() doesn't check the *poll.FD state before sending
      data, the client will only receive the response body with status and
      report "malformed http response/status code".
      
      This patch is to enable netpollcheckerr before sendfile, which should
      align with normal *poll.FD.Write() and Splice().
      
      For #43822
      Fixes #44294
      
      Change-Id: I32517e3f261bab883a58b577b813ef189214b954
      Reviewed-on: https://go-review.googlesource.com/c/go/+/285914
      
      
      Reviewed-by: default avatarEmmanuel Odeke <emmanuel@orijtech.com>
      Trust: Emmanuel Odeke <emmanuel@orijtech.com>
      Trust: Bryan C. Mills <bcmills@google.com>
      Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
      (cherry picked from commit f0d23c9d)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/296530
      Trust: Ian Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Go Bot <gobot@golang.org>
      30357d6e
  12. Feb 16, 2021
  13. Feb 04, 2021
  14. Feb 03, 2021
    • Ian Lance Taylor's avatar
      [release-branch.go1.15] runtime: don't adjust timer pp field in timerWaiting status · 3171f483
      Ian Lance Taylor authored
      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: default avatarMichael Knyszek <mknyszek@google.com>
      Reviewed-by: default avatarMichael Pratt <mpratt@google.com>
      (cherry picked from commit d2d155d1)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/287092
      Run-TryBot: Carlos Amedee <carlos@golang.org>
      3171f483
  15. Feb 02, 2021
  16. Feb 01, 2021
  17. Jan 22, 2021
  18. Jan 21, 2021
  19. Jan 20, 2021
  20. Jan 19, 2021
  21. Jan 16, 2021
Loading