linux-toradex.git/arch/arm64/kernel, branch v3.17.8

arm64: Add COMPAT_HWCAP_LPAE

2015-01-08T18:27:46+00:00

commit 7d57511d2dba03a8046c8b428dd9192a4bfc1e73 upstream.

Commit a469abd0f868 (ARM: elf: add new hwcap for identifying atomic
ldrd/strd instructions) introduces HWCAP_ELF for 32-bit ARM
applications. As LPAE is always present on arm64, report the
corresponding compat HWCAP to user space.

Signed-off-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

Correct the race condition in aarch64_insn_patch_text_sync()

2014-11-21T17:23:12+00:00

commit 899d5933b2dd2720f2b20b01eaa07871aa6ad096 upstream.

When experimenting with patches to provide kprobes support for aarch64
smp machines would hang when inserting breakpoints into kernel code.
The hangs were caused by a race condition in the code called by
aarch64_insn_patch_text_sync().  The first processor in the
aarch64_insn_patch_text_cb() function would patch the code while other
processors were still entering the function and incrementing the
cpu_count field.  This resulted in some processors never observing the
exit condition and exiting the function.  Thus, processors in the
system hung.

The first processor to enter the patching function performs the
patching and signals that the patching is complete with an increment
of the cpu_count field. When all the processors have incremented the
cpu_count field the cpu_count will be num_cpus_online()+1 and they
will return to normal execution.

Fixes: ae16480785de arm64: introduce interfaces to hotpatch kernel and module code
Signed-off-by: William Cohen 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: efi: Fix stub cache maintenance

2014-11-21T17:23:12+00:00

commit 9b0b26580a753d4d6bdd2b8b4ca9a8f3f2d39065 upstream.

While efi-entry.S mentions that efi_entry() will have relocated the
kernel image, it actually means that efi_entry will have placed a copy
of the kernel in the appropriate location, and until this is branched to
at the end of efi_entry.S, all instructions are executed from the
original image.

Thus while the flush in efi_entry.S does ensure that the copy is visible
to noncacheable accesses, it does not guarantee that this is true for
the image instructions are being executed from. This could have
disasterous effects when the MMU and caches are disabled if the image
has not been naturally evicted to the PoC.

Additionally, due to a missing dsb following the ic ialluis, the new
kernel image is not necessarily clean in the I-cache when it is branched
to, with similar potentially disasterous effects.

This patch adds additional flushing to ensure that the currently
executing stub text is flushed to the PoC and is thus visible to
noncacheable accesses. As it is placed after the instructions cache
maintenance for the new image and __flush_dcache_area already contains a
dsb, we do not need to add a separate barrier to ensure completion of
the icache maintenance.

Comments are updated to clarify the situation with regard to the two
images and the maintenance required for both.

Fixes: 3c7f255039a2ad6ee1e3890505caf0d029b22e29
Signed-off-by: Mark Rutland 
Acked-by: Joel Schopp 
Reviewed-by: Roy Franz 
Tested-by: Tom Lendacky 
Cc: Ard Biesheuvel 
Cc: Ian Campbell 
Cc: Leif Lindholm 
Cc: Mark Salter 
Cc: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: debug: don't re-enable debug exceptions on return from el1_dbg

2014-10-30T16:43:08+00:00

commit 1059c6bf8534acda249e7e65c81e7696fb074dc1 upstream.

When returning from a debug exception taken from EL1, we unmask debug
exceptions after handling the exception. This is crucial for debug
exceptions taken from EL0, so that any kernel work on the ret_to_user
path can be debugged by kgdb.

However, when returning back to EL1 the only thing left to do is to
restore the original register state before the exception return. If
single-step has been enabled by the debug exception handler, we will
get stuck in an infinite debug exception loop, since we will take the
step exception as soon as we unmask debug exceptions.

This patch avoids unmasking debug exceptions on the debug exception
return path when the exception was taken from EL1.

Fixes: 2a2830703a23 (arm64: debug: avoid accessing mdscr_el1 on fault paths where possible)
Reported-by: David Long 
Reported-by: AKASHI Takahiro 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: Tell irq work about self IPI support

2014-10-15T10:29:25+00:00

commit 3631073659d0aafeaa52227bb61a100efaf901dc upstream.

ARM64 irq work self-IPI support depends on __smp_cross_call to point to
some relevant IRQ controller operations. This information should be
available after the call to init_IRQ().

Lets implement arch_irq_work_has_interrupt() accordingly.

Acked-by: Peter Zijlstra (Intel) 
Acked-by: Catalin Marinas 
Cc: Ingo Molnar 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Signed-off-by: Frederic Weisbecker 
Signed-off-by: Greg Kroah-Hartman

arm64: flush TLS registers during exec

2014-09-11T17:34:58+00:00

Nathan reports that we leak TLS information from the parent context
during an exec, as we don't clear the TLS registers when flushing the
thread state.

This patch updates the flushing code so that we:

  (1) Unconditionally zero the tpidr_el0 register (since this is fully
      context switched for native tasks and zeroed for compat tasks)

  (2) Zero the tp_value state in thread_info before clearing the
      tpidrr0_el0 register for compat tasks (since this is only writable
      by the set_tls compat syscall and therefore not fully switched).

A missing compiler barrier is also added to the compat set_tls syscall.

Cc: 
Acked-by: Nathan Lynch 
Reported-by: Nathan Lynch 
Signed-off-by: Will Deacon

arm64: use irq_set_affinity with force=false when migrating irqs

2014-09-03T18:24:38+00:00

The arm64 interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. Originally
this argument had no effect because it was not used by any interrupt
chip driver and there was no semantics defined.

This changed with commit 01f8fa4f01d8 ("genirq: Allow forcing cpu
affinity of interrupts") which made the force argument useful to route
interrupts to not yet online cpus without checking the target cpu
against the cpu online mask. The following commit ffde1de64012
("irqchip: gic: Support forced affinity setting") implemented this for
the GIC interrupt controller.

As a consequence the cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validation against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.

Commit 601c942176d8("arm64: use cpu_online_mask when using forced
irq_set_affinity") intended to fix the above mentioned issue but
introduced another issue where affinity can be migrated to a wrong
CPU due to unconditional copy of cpu_online_mask.

As with for arm, solve the issue by calling irq_set_affinity() with
force=false from the CPU offline irq migration code so the GIC driver
validates the affinity mask against CPU online mask and therefore
removes CPU0 from the possible target candidates. Also revert the
changes done in the commit 601c942176d8 as it's no longer needed.

Tested on Juno platform.

Fixes: 601c942176d8("arm64: use cpu_online_mask when using forced
	irq_set_affinity")
Signed-off-by: Sudeep Holla 
Acked-by: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc:  # 3.10.x
Signed-off-by: Will Deacon

Revert "arm64: cpuinfo: print info for all CPUs"

2014-09-01T14:55:22+00:00

It turns out that vendors are relying on the format of /proc/cpuinfo,
and we've even spotted out-of-tree hacks attempting to make it look
identical to the format used by arch/arm/. That means we can't afford to
churn this interface in mainline, so revert the recent reformatting of
the file for arm64 pending discussions on the list to find out what
people actually want.

This reverts commit d7a49086f263164a2c4c178eb76412d48cd671d7.

Acked-by: Mark Rutland 
Signed-off-by: Will Deacon

arm64: fix bug for reloading FPSIMD state after cpu power off

2014-09-01T11:55:21+00:00

Now arm64 defers reloading FPSIMD state, but this optimization also
introduces the bug after cpu resume back from low power mode.

The reason is after the cpu has been powered off, s/w need set the
cpu's fpsimd_last_state to NULL so that it will force to reload
FPSIMD state for the thread, otherwise there has the chance to meet
the condition for both the task's fpsimd_state.cpu field contains the
id of the current cpu, and the cpu's fpsimd_last_state per-cpu variable
points to the task's fpsimd_state, so finally kernel will skip to reload
the context during it return back to userland.

Acked-by: Ard Biesheuvel 
Reviewed-by: Catalin Marinas 
Signed-off-by: Leo Yan 
Signed-off-by: Will Deacon

arm64: perf: don't rely on layout of pt_regs when grabbing sp or pc

2014-08-28T19:01:50+00:00

The current perf_regs code relies on sp and pc sitting just off the end
of the pt_regs->regs array. This is ugly and fragile, so this patch
checks for these register explicitly and returns the appropriate field.

Acked-by: Jean Pihet 
Signed-off-by: Will Deacon