kernel/git/stable/linux-stable.git/arch/arm/mm, branch linux-3.3.y

ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS

2012-05-21T17:46:18+00:00

commit 9b61a4d1b2064dbd0c9e61754305ac852170509f upstream. Reported-by: Al Viro Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7398/1: l2x0: only write to debug registers on PL310

2012-05-12T16:32:22+00:00

commit ab4d536890853ab6675ede65db40e2c0980cb0ea upstream. PL310 errata #588369 and #727915 require writes to the debug registers of the cache controller to work around known problems. Writing these registers on L220 may cause deadlock, so ensure that we only perform this operation when we identify a PL310 at probe time. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7397/1: l2x0: only apply workaround for erratum #753970 on PL310

2012-05-12T16:32:21+00:00

commit f154fe9b806574437b47f08e924ad10c0e240b23 upstream. The workaround for PL310 erratum #753970 can lead to deadlock on systems with an L220 cache controller. This patch makes the workaround effective only when the cache controller is identified as a PL310 at probe time. Signed-off-by: Will Deacon Signed-off-by: Russell King [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

ARM: 7396/1: errata: only handle ARM erratum #326103 on affected cores

2012-05-07T15:53:24+00:00

commit f0c4b8d653f5ee091fb8d4d02ed7eaad397491bb upstream. Erratum #326103 ("FSR write bit incorrect on a SWP to read-only memory") only affects the ARM 1136 core prior to r1p0. The workaround disassembles the faulting instruction to determine whether it was a read or write access on all v6 cores. An issue has been reported on the ARM 11MPCore whereby loading the faulting instruction may happen in parallel with that page being unmapped, resulting in a deadlock due to the lack of TLB broadcasting in hardware: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/091561.html This patch limits the workaround so that it is only used on affected cores, which are known to be UP only. Other v6 cores can rely on the FSR to indicate the access type correctly. Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE

2012-04-22T22:38:55+00:00

commit 078c04545ba56da21567728a909a496df5ff730d upstream. Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE register states are not saved/restored at context switch. The default state of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing covert communication - eg between userspace tasks running inside chroot jails. This patch sets up TEECR in order to prevent user-space access to TEEHBR when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to access TEEHBR. Reviewed-by: Will Deacon Signed-off-by: Jonathan Austin Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7345/1: errata: update workaround for A9 erratum #743622

2012-02-27T11:22:08+00:00

Erratum #743622 affects all r2 variants of the Cortex-A9 processor, so ensure that the workaround is applied regardless of the revision. Cc: Reported-by: Russell King Signed-off-by: Will Deacon Signed-off-by: Russell King

ARM: 7325/1: fix v7 boot with lockdep enabled

2012-02-15T21:09:52+00:00

Bootup with lockdep enabled has been broken on v7 since b46c0f74657d ("ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR"). This is because v7_setup (which is called very early during boot) calls v7_flush_dcache_all, and the save_and_disable_irqs added by that patch ends up attempting to call into lockdep C code (trace_hardirqs_off()) when we are in no position to execute it (no stack, MMU off). Fix this by using a notrace variant of save_and_disable_irqs. The code already uses the notrace variant of restore_irqs. Reviewed-by: Nicolas Pitre Acked-by: Stephen Boyd Cc: Catalin Marinas Cc: stable@vger.kernel.org Signed-off-by: Rabin Vincent Signed-off-by: Russell King

ARM: 7323/1: Do not allow ARM_LPAE on pre-ARMv7 architectures

2012-02-15T11:04:36+00:00

This patch expands the Kconfig dependencies for ARM_LPAE to not allow enabling when architectures other than ARMv7 are built into the kernel. Signed-off-by: Catalin Marinas Reported-by: Russell King Signed-off-by: Russell King

ARM: 7321/1: cache-v7: Disable preemption when reading CCSIDR

2012-02-09T16:25:37+00:00

armv7's flush_cache_all() flushes caches via set/way. To determine the cache attributes (line size, number of sets, etc.) the assembly first writes the CSSELR register to select a cache level and then reads the CCSIDR register. The CSSELR register is banked per-cpu and is used to determine which cache level CCSIDR reads. If the task is migrated between when the CSSELR is written and the CCSIDR is read the CCSIDR value may be for an unexpected cache level (for example L1 instead of L2) and incorrect cache flushing could occur. Disable interrupts across the write and read so that the correct cache attributes are read and used for the cache flushing routine. We disable interrupts instead of disabling preemption because the critical section is only 3 instructions and we want to call v7_dcache_flush_all from __v7_setup which doesn't have a full kernel stack with a struct thread_info. This fixes a problem we see in scm_call() when flush_cache_all() is called from preemptible context and sometimes the L2 cache is not properly flushed out. Signed-off-by: Stephen Boyd Acked-by: Catalin Marinas Reviewed-by: Nicolas Pitre Cc: stable@vger.kernel.org Signed-off-by: Russell King

Revert "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"

2012-02-02T17:37:41+00:00

This reverts commit 3c424f359898aff48c3d5bed608ac706f8a528c3. Joachim Eastwood reports: | "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping" | Commit: 3c424f359898aff48c3d5bed608ac706f8a528c3 in Linus master | | Breaks booting on my custom AT91RM9200 board. | There isn't any error messages or anything that indicates what goes | wrong it just stops after; Uncompressing Linux... done, booting the | kernel. | | Reverting it makes my board boot again. and further debugging reveals: ioremap: pfn=fffff phys=fffff000 offset=400 size=1000 ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000 ioremap: found: addr fef74000 => fed73000 => fed73400 Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn 0xfffff. This happens because the changed if statement becomes: if (0x00200 > 0xfffff || 0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1) and therefore: if (0x00200 > 0xfffff || 0x000003ff > 0x00203fff) The if condition fails, and so we _believe_ that the SRAM mapping fits our request. Clearly that's totally bogus. Moreover, the original premise of the 'fix' patch was wrong: | The condition checking boundaries of the requested and existing | mappings didn't take in-page offset into consideration though, | which lead to obscure and hard to debug problems when requested | mapping crossed end of the static one. as the code immediately above this loop does: size = PAGE_ALIGN(offset + size); so 'size' already contains the requested offset into the page. So, revert the broken 'fix'. Acked-by: Nicolas Pitre