1. 23 May, 2017 8 commits
    • Wade Simmons's avatar
      crypto/rand: only read necessary bytes for Int · 8a2553e3
      Wade Simmons authored
      We only need to read the number of bytes required to store the value
      "max - 1" to generate a random number in the range [0, max).
      
      Before, there was an off-by-one error where an extra byte was read from
      the io.Reader for inputs like "256" (right at the boundary for a byte).
      There was a similar off-by-one error in the logic for clearing bits and
      thus for any input that was a power of 2, there was a 50% chance the
      read would continue to be retried as the mask failed to remove a bit.
      
      Fixes #18165.
      
      Change-Id: I548c1368990e23e365591e77980e9086fafb6518
      Reviewed-on: https://go-review.googlesource.com/43891Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      8a2553e3
    • Austin Clements's avatar
      runtime: remove unused copies of special stack guards · 9f03e895
      Austin Clements authored
      There are two copies each of the stackPreempt/_StackPreempt and
      stackFork/_StackFork constants. Remove the ones left over from C that
      are no longer used.
      
      Change-Id: I849604c72c11e4a0cb08e45e9817eb3f5a6ce8ba
      Reviewed-on: https://go-review.googlesource.com/43638Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      9f03e895
    • Austin Clements's avatar
      runtime: fix stackCache=0 debug mode · 47542520
      Austin Clements authored
      Setting stackCache to 0 to disable stack caches for debugging hasn't
      worked for a long time. It causes stackalloc to fall back to full span
      allocation, round sub-page stacks down to 0 pages, and blow up.
      
      Fix this debug mode so it disables the per-P caches, but continues to
      use the global stack pools for small stacks, which correctly handle
      sub-page stacks. While we're here, rename stackCache to stackNoCache
      so it acts like the rest of the stack allocator debug modes where "0"
      is the right default value.
      
      Fixes #17291.
      
      Change-Id: If401c41cee3448513cbd7bb2e9334a8efab257a7
      Reviewed-on: https://go-review.googlesource.com/43637Reviewed-by: default avatarKeith Randall <khr@golang.org>
      47542520
    • Austin Clements's avatar
      runtime: fix stackFromSystem returning memory · 8a1c5b2e
      Austin Clements authored
      The stackFromSystem debug mode has two problems:
      
      1) It rounds the stack allocation to _PageSize. If the physical page
      size is >8K, this can cause unmapping the memory later to either
      under-unmap or over-unmap.
      
      2) It doesn't return the rounded-up allocation size to its caller, so
      when we later unmap the memory, we may pass the wrong length.
      
      Fix these problems by rounding the size up to the physical page size
      and putting that rounded-up size in the returned stack bounds.
      
      Fixes #17289.
      
      Change-Id: I6b854af3b06bb16e3750798397bb5e2a722ec1cb
      Reviewed-on: https://go-review.googlesource.com/43636Reviewed-by: default avatarKeith Randall <khr@golang.org>
      8a1c5b2e
    • Chris Broadfoot's avatar
      doc: document go1.8.2 and go1.7.6 · e16944da
      Chris Broadfoot authored
      Change-Id: I2ed2e8c4890a65288cf3066ebe3c1d9a16fb4c05
      Reviewed-on: https://go-review.googlesource.com/43990Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      e16944da
    • Austin Clements's avatar
      runtime: don't corrupt arena bounds on low mmap · e5a5c03f
      Austin Clements authored
      If mheap.sysAlloc doesn't have room in the heap arena for an
      allocation, it will attempt to map more address space with sysReserve.
      sysReserve is given a hint, but can return any unused address range.
      Currently, mheap.sysAlloc incorrectly assumes the returned region will
      never fall between arena_start and arena_used. If it does,
      mheap.sysAlloc will blindly accept the new region as the new
      arena_used and arena_end, causing these to decrease and make it so any
      Go heap above the new arena_used is no longer considered part of the
      Go heap. This assumption *used to be* safe because we had all memory
      between arena_start and arena_used mapped, but when we switched to an
      arena_start of 0 on 32-bit, it became no longer safe.
      
      Most likely, we've only recently seen this bug occur because we
      usually start arena_used just above the binary, which is low in the
      address space. Hence, the kernel is very unlikely to give us a region
      before arena_used.
      
      Since mheap.sysAlloc is a linear allocator, there's not much we can do
      to handle this well. Hence, we fix this problem by simply rejecting
      the new region if it isn't after arena_end. In this case, we'll take
      the fall-back path and mmap a small region at any address just for the
      requested memory.
      
      Fixes #20259.
      
      Change-Id: Ib72e8cd621545002d595c7cade1e817cfe3e5b1e
      Reviewed-on: https://go-review.googlesource.com/43870Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default avatarRick Hudson <rlh@golang.org>
      e5a5c03f
    • Joe Richey joerichey@google.com's avatar
      crypto/rand: use blocking getrandom call on Linux when supported · 95d991d3
      Joe Richey joerichey@google.com authored
      By changing getRandomLinux to immediately use the getrandom() syscall
      without GRND_NONBLOCK, we now only fall back to reading from
      /dev/urandom on Linux if the kernel does not support the getrandom()
      syscall. This means reads for crypto/rand will now block if the kernel
      has insufficient entropy on Linux kernels after v3.16.
      
      Before, if the kernel had insufficient entropy, it would fall back to
      reading from /dev/urandom. This would potentially return predictable
      data.
      
      Fixes #19274
      
      Change-Id: I1cb081ce2f3096f18ad2820e52ecdbd993dc2afc
      Reviewed-on: https://go-review.googlesource.com/43852Reviewed-by: default avatarFilippo Valsorda <hi@filippo.io>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      95d991d3
    • Alex Brainman's avatar
      os/exec: ignore some pipe write errors on windows · f3f29d1d
      Alex Brainman authored
      This change is windows version of CL 12152.
      It also extends test to cover scenarios reported on issue #20445.
      Some source files copied and renamed to make code clearer.
      
      Fixes #20445
      
      Change-Id: Idd2f636f27c6bd5cfe98017ba2df911358263382
      Reviewed-on: https://go-review.googlesource.com/43910
      Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      f3f29d1d
  2. 22 May, 2017 14 commits
  3. 20 May, 2017 2 commits
  4. 19 May, 2017 12 commits
  5. 18 May, 2017 4 commits