• Austin Clements's avatar
    runtime: support smaller physical pages than PhysPageSize · f407ca92
    Austin Clements authored
    Most operations need an upper bound on the physical page size, which
    is what sys.PhysPageSize is for (this is checked at runtime init on
    Linux). However, a few operations need a *lower* bound on the physical
    page size. Introduce a "minPhysPageSize" constant to act as this lower
    bound and use it where it makes sense:
    
    1) In addrspace_free, we have to query each page in the given range.
       Currently we increment by the upper bound on the physical page
       size, which means we may skip over pages if the true size is
       smaller. Worse, we currently pass a result buffer that only has
       enough room for one page. If there are actually multiple pages in
       the range passed to mincore, the kernel will overflow this buffer.
       Fix these problems by incrementing by the lower-bound on the
       physical page size and by passing "1" for the length, which the
       kernel will round up to the true physical page size.
    
    2) In the write barrier, the bad pointer check tests for pointers to
       the first physical page, which are presumably small integers
       masquerading as pointers. However, if physical pages are smaller
       than we think, we may have legitimate pointers below
       sys.PhysPageSize. Hence, use minPhysPageSize for this test since
       pointers should never fall below that.
    
    In particular, this applies to ARM64 and MIPS. The runtime is
    configured to use 64kB pages on ARM64, but by default Linux uses 4kB
    pages. Similarly, the runtime assumes 16kB pages on MIPS, but both 4kB
    and 16kB kernel configurations are common. This also applies to ARM on
    systems where the runtime is recompiled to deal with a larger page
    size. It is also a step toward making the runtime use only a
    dynamically-queried page size.
    
    Change-Id: I1fdfd18f6e7cbca170cc100354b9faa22fde8a69
    Reviewed-on: https://go-review.googlesource.com/25020Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
    Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
    Run-TryBot: Austin Clements <austin@google.com>
    f407ca92
mbarrier.go 10.2 KB