linux-stable.git/arch/arm/kernel, branch v3.10.78

ARM: fix asm/memory.h build error

2015-02-06T06:35:39+00:00

commit b713aa0b15015a65ad5421543b80df86de043d62 upstream.

Jason Gunthorpe reports a build failure when ARM_PATCH_PHYS_VIRT is
not defined:

In file included from arch/arm/include/asm/page.h:163:0,
                 from include/linux/mm_types.h:16,
                 from include/linux/sched.h:24,
                 from arch/arm/kernel/asm-offsets.c:13:
arch/arm/include/asm/memory.h: In function '__virt_to_phys':
arch/arm/include/asm/memory.h:244:40: error: 'PHYS_OFFSET' undeclared (first use in this function)
arch/arm/include/asm/memory.h:244:40: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/include/asm/memory.h: In function '__phys_to_virt':
arch/arm/include/asm/memory.h:249:13: error: 'PHYS_OFFSET' undeclared (first use in this function)

Fixes: ca5a45c06cd4 ("ARM: mm: use phys_addr_t appropriately in p2v and v2p conversions")
Tested-By: Jason Gunthorpe 
Signed-off-by: Russell King 
[hpy: Backported to 3.10:
 - adjust the context
 - MPU is not supported by 3.10, so ignore fix to MPU compared with the original patch.]
Signed-off-by: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: 7829/1: Add ".text.unlikely" and ".text.hot" to arm unwind tables

2015-02-06T06:35:38+00:00

commit 849b882b52df0f276d9ffded01d85654aa0da422 upstream.

It appears that gcc may put some code in ".text.unlikely" or
".text.hot" sections.  Right now those aren't accounted for in unwind
tables.  Add them.

I found some docs about this at:
  http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc.pdf

Without this, if you have slub_debug turned on, you can get messages
that look like this:
  unwind: Index not found 7f008c50

Signed-off-by: Doug Anderson 
Acked-by: Mike Frysinger 
Signed-off-by: Russell King 
[wangkai: backport to 3.10
	- adjust context
]
Signed-off-by: Wang Kai 
Signed-off-by: Greg Kroah-Hartman

ARM: sched_clock: Load cycle count after epoch stabilizes

2014-12-16T17:09:43+00:00

commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf upstream.

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

 CPU0                           CPU1
 ----                           ----
 cyc = read_sched_clock()
 cyc_to_sched_clock()
                                 update_sched_clock()
                                  ...
                                  cd.epoch_cyc = cyc;
  epoch_cyc = cd.epoch_cyc;
  ...
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Cc: Russell King 
Signed-off-by: Stephen Boyd 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

ARM: Correct BUG() assembly to ensure it is endian-agnostic

2014-11-21T17:22:55+00:00

commit 63328070eff2f4fd730c86966a0dbc976147c39f upstream.

Currently BUG() uses .word or .hword to create the necessary illegal
instructions. However if we are building BE8 then these get swapped
by the linker into different illegal instructions in the text. This
means that the BUG() macro does not get trapped properly.

Change to using  to provide the necessary ARM instruction
building as we cannot rely on gcc/gas having the `.inst` instructions
which where added to try and resolve this issue (reported by Dave Martin
).

Signed-off-by: Ben Dooks 
Reviewed-by: Dave Martin 
Cc: Wang Nan 
Signed-off-by: Greg Kroah-Hartman

ARM: probes: fix instruction fetch order with

2014-11-21T17:22:54+00:00

commit 888be25402021a425da3e85e2d5a954d7509286e upstream.

If we are running BE8, the data and instruction endianness do not
match, so use  to correctly translate memory accesses
into ARM instructions.

Acked-by: Jon Medhurst 
Signed-off-by: Ben Dooks 
[taras.kondratiuk@linaro.org: fixed Thumb instruction fetch order]
Signed-off-by: Taras Kondratiuk 
[wangnan: backport to 3.10 and 3.14:
 - adjust context
 - backport all changes on arch/arm/kernel/probes.c to
   arch/arm/kernel/kprobes-common.c since we don't have
   commit c18377c303787ded44b7decd7dee694db0f205e9.
 - After the above adjustments, becomes same to Taras Kondratiuk's
   original patch:
     http://lists.linaro.org/pipermail/linaro-kernel/2014-January/010346.html
]
Signed-off-by: Wang Nan 
Signed-off-by: Greg Kroah-Hartman

ARM: 7748/1: oabi: handle faults when loading swi instruction from userspace

2014-10-05T21:54:15+00:00

commit 1aa2b3b7a6c4f3dbd3671171113a20e6a6190e3b upstream.

Running an OABI_COMPAT kernel on an SMP platform can lead to fun and
games with page aging.

If one CPU issues a swi instruction immediately before another CPU
decides to mkold the page containing the swi instruction, then we will
fault attempting to load the instruction during the vector_swi handler
in order to retrieve its immediate field. Since this fault is not
currently dealt with by our exception tables, this results in a panic:

  Unable to handle kernel paging request at virtual address 4020841c
  pgd = c490c000
  [4020841c] *pgd=84451831, *pte=bf05859d, *ppte=00000000
  Internal error: Oops: 17 [#1] PREEMPT SMP ARM
  Modules linked in: hid_sony(O)
  CPU: 1    Tainted: G        W  O  (3.4.0-perf-gf496dca-01162-gcbcc62b #1)
  PC is at vector_swi+0x28/0x88
  LR is at 0x40208420

This patch wraps all of the swi instruction loads with the USER macro
and provides a shared exception table entry which simply rewinds the
saved user PC and returns from the system call (without setting tbl, so
there's no worries with tracing or syscall restarting). Returning to
userspace will re-enter the page fault handler, from where we will
probably send SIGSEGV to the current task.

Reported-by: Wang, Yalin 
Reviewed-by: Nicolas Pitre 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Cc: Sheng Yong 
Signed-off-by: Greg Kroah-Hartman

ARM: 7897/1: kexec: Use the right ISA for relocate_new_kernel

2014-10-05T21:54:10+00:00

commit e2ccba49085ab5d71b092de2a5176eb9b19cc876 upstream.

Copying a function with memcpy() and then trying to execute the
result isn't trivially portable to Thumb.

This patch modifies the kexec soft restart code to copy its
assembler trampoline relocate_new_kernel() using fncpy() instead,
so that relocate_new_kernel can be in the same ISA as the rest of
the kernel without problems.

Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Reported-by: Taras Kondratiuk 
Tested-by: Taras Kondratiuk 
Signed-off-by: Russell King 
Integrated-by: Liu Hua 
Signed-off-by: Liu Hua 
Signed-off-by: Greg Kroah-Hartman

ARM: 8133/1: use irq_set_affinity with force=false when migrating irqs

2014-10-05T21:54:10+00:00

commit a040803a9d6b8c1876d3487a5cb69602ebcbb82c upstream.

Since commit 1dbfa187dad ("ARM: irq migration: force migration off CPU
going down") the ARM interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. At the point
of this change the 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 ARM cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validataion against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.

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.

Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
locks up as the IRQs are not migrated away from CPU0.

Signed-off-by: Sudeep Holla 
Acked-by: Thomas Gleixner 
Acked-by: Mark Rutland 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: stacktrace: avoid listing stacktrace functions in stacktrace

2014-07-01T03:09:44+00:00

commit 3683f44c42e991d313dc301504ee0fca1aeb8580 upstream.

While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as follows:

 [] save_stack_trace_tsk+0x0/0x98
 [] save_stack_trace+0x24/0x28
 ...

This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong
thing (which is the number of stack frames to avoid recording.)

Perversely, it does the right thing when passed a non-current thread.  Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.

Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: perf: hook up perf_sample_event_took around pmu irq handling

2014-06-11T19:03:27+00:00

commit 5f5092e72cc25a6a5785308270e0085b2b2772cc upstream.

Since we indirect all of our PMU IRQ handling through a dispatcher, it's
trivial to hook up perf_sample_event_took to prevent applications such
as oprofile from generating interrupt storms due to an unrealisticly
low sample period.

Reported-by: Robert Richter 
Signed-off-by: Will Deacon 
Cc: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman