1. 29 Jun, 2017 2 commits
  2. 26 Jun, 2017 3 commits
  3. 23 Jun, 2017 2 commits
    • Mark Rutland's avatar
      arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels · 8486e54d
      Mark Rutland authored
      When a kernel is built without CONFIG_ARM64_MODULE_PLTS, we don't
      generate the expected branch instruction in ftrace_make_nop(). This
      means we pass zero (rather than a valid branch) to ftrace_modify_code()
      as the expected instruction to validate. This causes us to return
      -EINVAL to the core ftrace code for a valid case, resulting in a splat
      at boot time.
      
      This was an unintended effect of commit:
      
        68764420 ("arm64: ftrace: fix building without CONFIG_MODULES")
      
      ... which incorrectly moved the generation of the branch instruction
      into the ifdef for CONFIG_ARM64_MODULE_PLTS.
      
      This patch fixes the issue by moving the ifdef inside of the relevant
      if-else case, and always checking that the branch is in range,
      regardless of CONFIG_ARM64_MODULE_PLTS. This ensures that we generate
      the expected branch instruction, and also improves our sanity checks.
      
      For consistency, both ftrace_make_nop() and ftrace_make_call() are
      updated with this pattern.
      
      Fixes: 68764420 ("arm64: ftrace: fix building without CONFIG_MODULES")
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8486e54d
    • Dave Martin's avatar
      arm64: signal: Allow expansion of the signal frame · 33f08261
      Dave Martin authored
      This patch defines an extra_context signal frame record that can be
      used to describe an expanded signal frame, and modifies the context
      block allocator and signal frame setup and parsing code to create,
      populate, parse and decode this block as necessary.
      
      To avoid abuse by userspace, parse_user_sigframe() attempts to
      ensure that:
      
       * no more than one extra_context is accepted;
       * the extra context data is a sensible size, and properly placed
         and aligned.
      
      The extra_context data is required to start at the first 16-byte
      aligned address immediately after the dummy terminator record
      following extra_context in rt_sigframe.__reserved[] (as ensured
      during signal delivery).  This serves as a sanity-check that the
      signal frame has not been moved or copied without taking the extra
      data into account.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      [will: add __force annotation when casting extra_datap to __user pointer]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      33f08261
  4. 22 Jun, 2017 19 commits
  5. 20 Jun, 2017 9 commits
    • Will Deacon's avatar
      Merge branch 'uuid-types' of git://git.infradead.org/users/hch/uuid into aarch64/for-next/ras-apei · dd19802f
      Will Deacon authored
      Pull in uuid-types branch from Christoph, since this conflicts heavily
      with the ACPI/APEI RAS work from Tyler Baicer and was created as an
      immutable branch to avoid conflicts with ACPI development.
      dd19802f
    • Luc Van Oostenryck's avatar
      arm64: pass machine size to sparse · f5d28490
      Luc Van Oostenryck authored
      When using sparse on the arm64 tree we get many thousands of
      warnings like 'constant ... is so big it is unsigned long long'
      or 'shift too big (32) for type unsigned long'. This happens
      because by default sparse considers the machine as 32bit and
      defines the size of the types accordingly.
      
      Fix this by passing the '-m64' flag to sparse so that
      sparse can correctly define longs as being 64bit.
      
      CC: Catalin Marinas <catalin.marinas@arm.com>
      CC: Will Deacon <will.deacon@arm.com>
      CC: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f5d28490
    • Dave Martin's avatar
      arm64: signal: factor out signal frame record allocation · bb4322f7
      Dave Martin authored
      This patch factors out the allocator for signal frame optional
      records into a separate function, to ensure consistency and
      facilitate later expansion.
      
      No overrun checking is currently done, because the allocation is in
      user memory and anyway the kernel never tries to allocate enough
      space in the signal frame yet for an overrun to occur.  This
      behaviour will be refined in future patches.
      
      The approach taken in this patch to allocation of the terminator
      record is not very clean: this will also be replaced in subsequent
      patches.
      
      For future extension, a comment is added in sigcontext.h
      documenting the current static allocations in __reserved[].  This
      will be important for determining under what circumstances
      userspace may or may not see an expanded signal frame.
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      bb4322f7
    • Dave Martin's avatar
      arm64: signal: factor frame layout and population into separate passes · bb4891a6
      Dave Martin authored
      In preparation for expanding the signal frame, this patch refactors
      the signal frame setup code in setup_sigframe() into two separate
      passes.
      
      The first pass, setup_sigframe_layout(), determines the size of the
      signal frame and its internal layout, including the presence and
      location of optional records.  The resulting knowledge is used to
      allocate and locate the user stack space required for the signal
      frame and to determine which optional records to include.
      
      The second pass, setup_sigframe(), is called once the stack frame
      is allocated in order to populate it with the necessary context
      information.
      
      As a result of these changes, it becomes more natural to represent
      locations in the signal frame by a base pointer and an offset,
      since the absolute address of each location is not known during the
      layout pass.  To be more consistent with this logic,
      parse_user_sigframe() is refactored to describe signal frame
      locations in a similar way.
      
      This change has no effect on the signal ABI, but will make it
      easier to expand the signal frame in future patches.
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      bb4891a6
    • Dave Martin's avatar
      arm64: signal: Refactor sigcontext parsing in rt_sigreturn · 47ccb028
      Dave Martin authored
      Currently, rt_sigreturn does very limited checking on the
      sigcontext coming from userspace.
      
      Future additions to the sigcontext data will increase the potential
      for surprises.  Also, it is not clear whether the sigcontext
      extension records are supposed to occur in a particular order.
      
      To allow the parsing code to be extended more easily, this patch
      factors out the sigcontext parsing into a separate function, and
      adds extra checks to validate the well-formedness of the sigcontext
      structure.
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      47ccb028
    • Dave Martin's avatar
      arm64: signal: split frame link record from sigcontext structure · 20987de3
      Dave Martin authored
      In order to be able to increase the amount of the data currently
      written to the __reserved[] array in the signal frame, it is
      necessary to overwrite the locations currently occupied by the
      {fp,lr} frame link record pushed at the top of the signal stack.
      
      In order for this to work, this patch detaches the frame link
      record from struct rt_sigframe and places it separately at the top
      of the signal stack.  This will allow subsequent patches to insert
      data between it and __reserved[].
      
      This change relies on the non-ABI status of the placement of the
      frame record with respect to struct sigframe: this status is
      undocumented, but the placement is not declared or described in the
      user headers, and known unwinder implementations (libgcc,
      libunwind, gdb) appear not to rely on it.
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      20987de3
    • Ard Biesheuvel's avatar
      arm64: mm: select CONFIG_ARCH_PROC_KCORE_TEXT · 8f360948
      Ard Biesheuvel authored
      To avoid issues with the /proc/kcore code getting confused about the
      kernels block mappings in the VMALLOC region, enable the existing
      facility that describes the [_text, _end) interval as a separate
      KCORE_TEXT region, which supersedes the KCORE_VMALLOC region that
      it intersects with on arm64.
      Reported-by: default avatarTan Xiaojun <tanxiaojun@huawei.com>
      Tested-by: default avatarTan Xiaojun <tanxiaojun@huawei.com>
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarLaura Abbott <labbott@redhat.com>
      Reviewed-by: default avatarJiri Olsa <jolsa@kernel.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8f360948
    • Ard Biesheuvel's avatar
      fs/proc: kcore: use kcore_list type to check for vmalloc/module address · 737326aa
      Ard Biesheuvel authored
      Instead of passing each start address into is_vmalloc_or_module_addr()
      to decide whether it falls into either the VMALLOC or the MODULES region,
      we can simply check the type field of the current kcore_list entry, since
      it will be set to KCORE_VMALLOC based on exactly the same conditions.
      
      As a bonus, when reading the KCORE_TEXT region on architectures that have
      one, this will avoid using vread() on the region if it happens to intersect
      with a KCORE_VMALLOC region. This is due the fact that the KCORE_TEXT
      region is the first one to be added to the kcore region list.
      Reported-by: default avatarTan Xiaojun <tanxiaojun@huawei.com>
      Tested-by: default avatarTan Xiaojun <tanxiaojun@huawei.com>
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarLaura Abbott <labbott@redhat.com>
      Reviewed-by: default avatarJiri Olsa <jolsa@kernel.org>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      737326aa
    • Ard Biesheuvel's avatar
      drivers/char: kmem: disable on arm64 · 06c35ef1
      Ard Biesheuvel authored
      As it turns out, arm64 deviates from other architectures in the way it
      maps the VMALLOC region: on most (all?) other architectures, it resides
      strictly above the kernel's direct mapping of DRAM, but on arm64, this
      is the other way around. For instance, for a 48-bit VA configuration,
      we have
      
        modules : 0xffff000000000000 - 0xffff000008000000   (   128 MB)
        vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000   (129022 GB)
        ...
        vmemmap : 0xffff7e0000000000 - 0xffff800000000000   (  2048 GB maximum)
                  0xffff7e0000000000 - 0xffff7e0003ff0000   (    63 MB actual)
        memory  : 0xffff800000000000 - 0xffff8000ffc00000   (  4092 MB)
      
      This has mostly gone unnoticed until now, but it does appear that it
      breaks an assumption in the kmem read/write code, which does something
      like
      
        if (p < (unsigned long) high_memory) {
          ... use straight copy_[to|from]_user() using p as virtual address ...
        }
        ...
        if (count > 0) {
          ... use vread/vwrite for accesses past high_memory ...
        }
      
      The first condition will inadvertently hold for the VMALLOC region if
      VMALLOC_START < PAGE_OFFSET [which is the case on arm64], but the read
      or write will subsequently fail the virt_addr_valid() check, resulting
      in a -ENXIO return value.
      
      Given how kmem seems to be living in borrowed time anyway, and given
      the fact that nobody noticed that the read/write interface is broken
      on arm64 in the first place, let's not bother trying to fix it, but
      simply disable the /dev/kmem interface entirely for arm64.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      06c35ef1
  6. 15 Jun, 2017 5 commits