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

ARM: 7819/1: fiq: Cast the first argument of flush_icache_range()

2015-08-17T03:51:42+00:00

commit 7cb3be0a27805c625ff7cce20c53c926d9483243 upstream.

Commit 2ba85e7af4 (ARM: Fix FIQ code on VIVT CPUs) causes the following build warning:

arch/arm/kernel/fiq.c:92:3: warning: passing argument 1 of 'cpu_cache.coherent_kern_range' makes integer from pointer without a cast [enabled by default]

Cast it as '(unsigned long)base' to avoid the warning.

Signed-off-by: Fabio Estevam 
Signed-off-by: Russell King 
Cc: Martin Kaiser 
Signed-off-by: Greg Kroah-Hartman

ARM: Fix FIQ code on VIVT CPUs

2015-08-17T03:51:41+00:00

commit 2ba85e7af4c639d933c9a87a6d7363f2983d5ada upstream.

Aaro Koskinen reports the following oops:
Installing fiq handler from c001b110, length 0x164
Unable to handle kernel paging request at virtual address ffff1224
pgd = c0004000
[ffff1224] *pgd=00000000, *pte=11fff0cb, *ppte=11fff00a
...
[] (set_fiq_handler+0x0/0x6c) from [] (ams_delta_init_fiq+0xa8/0x160)
 r6:00000164 r5:c001b110 r4:00000000 r3:fefecb4c
[] (ams_delta_init_fiq+0x0/0x160) from [] (ams_delta_init+0xd4/0x114)
 r6:00000000 r5:fffece10 r4:c037a9e0
[] (ams_delta_init+0x0/0x114) from [] (customize_machine+0x24/0x30)

This is because the vectors page is now write-protected, and to change
code in there we must write to its original alias.  Make that change,
and adjust the cache flushing such that the code will become visible
to the instruction stream on VIVT CPUs.

Reported-by: Aaro Koskinen 
Tested-by: Aaro Koskinen 
Signed-off-by: Russell King 
Cc: Martin Kaiser 
Signed-off-by: Greg Kroah-Hartman

ARM: Fix !kuser helpers case

2015-08-17T03:51:41+00:00

commit 1b16c4bcf80e319b2226a886b72b8466179c8e3a upstream.

Fix yet another build failure caused by a weird set of configuration
settings:

  LD      init/built-in.o
arch/arm/kernel/built-in.o: In function `__dabt_usr':
/home/tom3q/kernel/arch/arm/kernel/entry-armv.S:377: undefined reference to `kuser_cmpxchg64_fixup'
arch/arm/kernel/built-in.o: In function `__irq_usr':
/home/tom3q/kernel/arch/arm/kernel/entry-armv.S:387: undefined reference to `kuser_cmpxchg64_fixup'

caused by:
CONFIG_KUSER_HELPERS=n
CONFIG_CPU_32v6K=n
CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG=n

Reported-by: Tomasz Figa 
Signed-off-by: Russell King 
Cc: Martin Kaiser 
Signed-off-by: Greg Kroah-Hartman

ARM: fix missing syscall trace exit

2015-06-06T06:19:59+00:00

commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.

Josh Stone reports:

  I've discovered a case where both arm and arm64 will miss a ptrace
  syscall-exit that they should report.  If the syscall is entered
  without TIF_SYSCALL_TRACE set, then it goes on the fast path.  It's
  then possible to have TIF_SYSCALL_TRACE added in the middle of the
  syscall, but ret_fast_syscall doesn't check this flag again.

Fix this by always checking for a syscall trace in the fast exit path.

Reported-by: Josh Stone 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

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