Skip to content

L
linux
Switch branch/tag
  1. 29 Jun, 2017 2 commits
  3. 26 Jun, 2017 3 commits
  5. 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
  7. 22 Jun, 2017 19 commits
  9. 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
  11. 15 Jun, 2017 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7