linux-stable.git/arch/arm, branch v3.3.7 Linux kernel stable tree ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS 2012-05-21T17:46:18+00:00 Russell King rmk+kernel@arm.linux.org.uk 2012-05-16T14:19:20+00:00 4d650fc196b3d6a600edfb7ed72ac72b47ea6185 commit 9b61a4d1b2064dbd0c9e61754305ac852170509f upstream. Reported-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9b61a4d1b2064dbd0c9e61754305ac852170509f upstream.

Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7417/1: vfp: ensure preemption is disabled when enabling VFP access 2012-05-21T17:46:18+00:00 Will Deacon will.deacon@arm.com 2012-05-11T16:42:37+00:00 a2e4e710c086666027b14bfcc4ca7c46773a7d6e commit 998de4acb2ba188d20768d1065658377a2e7d29b upstream. The vfp_enable function enables access to the VFP co-processor register space (cp10 and cp11) on the current CPU and must be called with preemption disabled. Unfortunately, the vfp_init late initcall does not disable preemption and can lead to an oops during boot if thread migration occurs at the wrong time and we end up attempting to access the FPSID on a CPU with VFP access disabled. This patch fixes the initcall to call vfp_enable from a non-preemptible context on each CPU and adds a BUG_ON(preemptible) to ensure that any similar problems are easily spotted in the future. Reported-by: Hyungwoo Yang <hwoo.yang@gmail.com> Signed-off-by: Hyungwoo Yang <hyungwooy@nvidia.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 998de4acb2ba188d20768d1065658377a2e7d29b upstream.

The vfp_enable function enables access to the VFP co-processor register
space (cp10 and cp11) on the current CPU and must be called with
preemption disabled. Unfortunately, the vfp_init late initcall does not
disable preemption and can lead to an oops during boot if thread
migration occurs at the wrong time and we end up attempting to access
the FPSID on a CPU with VFP access disabled.

This patch fixes the initcall to call vfp_enable from a non-preemptible
context on each CPU and adds a BUG_ON(preemptible) to ensure that any
similar problems are easily spotted in the future.

Reported-by: Hyungwoo Yang <hwoo.yang@gmail.com>
Signed-off-by: Hyungwoo Yang <hyungwooy@nvidia.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7398/1: l2x0: only write to debug registers on PL310 2012-05-12T16:32:22+00:00 Will Deacon will.deacon@arm.com 2012-04-20T16:22:11+00:00 f3d426d5b791e91a0c515ac8f9dbf9e16dc439e6 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 <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7397/1: l2x0: only apply workaround for erratum #753970 on PL310 2012-05-12T16:32:21+00:00 Will Deacon will.deacon@arm.com 2012-04-20T16:21:08+00:00 c2fa9282ae75212b61077b274bf69d89890362e5 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 <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: OMAP: Revert "ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields" 2012-05-12T16:32:17+00:00 Archit Taneja archit@ti.com 2012-04-19T12:09:16+00:00 f4fad1b66f36116d8ac4f58c357ea077179c8e84 commit 08ca7444f589bedf9ad5d82883e5d0754852d73b upstream. This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237. The commit above swapped the DSI1_PPID and DSI2_PPID register fields in CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V). With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs. After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was pulling up voltage on DSI2 lanes. This proves that the current version of OMAP4 TRM is incorrect, swap the position of register fields according to the older TRM versions as they were correct. Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 08ca7444f589bedf9ad5d82883e5d0754852d73b upstream.

This reverts commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237.

The commit above swapped the DSI1_PPID and DSI2_PPID register fields in
CONTROL_DSIPHY to be in sync with the newer public OMAP TRMs(after version V).

With this commit, contention errors were reported on DSI lanes some OMAP4 SDPs.
After probing the DSI lanes on OMAP4 SDP, it was seen that setting bits in the
DSI2_PPID field was pulling up voltage on DSI1 lanes, and DSI1_PPID field was
pulling up voltage on DSI2 lanes.

This proves that the current version of OMAP4 TRM is incorrect, swap the
position of register fields according to the older TRM versions as they were
correct.

Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: orion5x: Fix GPIO enable bits for MPP9 2012-05-12T16:32:17+00:00 Ben Hutchings ben@decadent.org.uk 2012-04-08T04:18:53+00:00 ddfe373c202b9d3a079365040855a0d297421bce commit 48d99f47a81a66bdd61a348c7fe8df5a7afdf5f3 upstream. Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 ('ARM: orion5x: Refactor mpp code to use common orion platform mpp.') seems to have accidentally inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform which uses MPP9 as a GPIO LED device, this results in the error: [ 12.711476] leds-gpio: probe of leds-gpio failed with error -22 Reported-by: Henry von Tresckow <hvontres@gmail.com> References: http://bugs.debian.org/667446 Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Tested-by: Hans Henry von Tresckow <hvontres@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 48d99f47a81a66bdd61a348c7fe8df5a7afdf5f3 upstream.

Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 ('ARM: orion5x: Refactor
mpp code to use common orion platform mpp.') seems to have accidentally
inverted the GPIO valid bits for MPP9 (only).  For the mv2120 platform
which uses MPP9 as a GPIO LED device, this results in the error:

[   12.711476] leds-gpio: probe of leds-gpio failed with error -22

Reported-by: Henry von Tresckow <hvontres@gmail.com>
References: http://bugs.debian.org/667446
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Hans Henry von Tresckow <hvontres@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7414/1: SMP: prevent use of the console when using idmap_pgd 2012-05-12T16:32:17+00:00 Colin Cross ccross@android.com 2012-05-05T19:58:13+00:00 c35fda8ad637d6f86fad00139f7faaf3d1133302 commit fde165b2a29673aabf18ceff14dea1f1cfb0daad upstream. Commit 4e8ee7de227e3ab9a72040b448ad728c5428a042 (ARM: SMP: use idmap_pgd for mapping MMU enable during secondary booting) switched secondary boot to use idmap_pgd, which is initialized during early_initcall, instead of a page table initialized during __cpu_up. This causes idmap_pgd to contain the static mappings but be missing all dynamic mappings. If a console is registered that creates a dynamic mapping, the printk in secondary_start_kernel will trigger a data abort on the missing mapping before the exception handlers have been initialized, leading to a hang. Initial boot is not affected because no consoles have been registered, and resume is usually not affected because the offending console is suspended. Onlining a cpu with hotplug triggers the problem. A workaround is to the printk in secondary_start_kernel until after the page tables have been switched back to init_mm. Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fde165b2a29673aabf18ceff14dea1f1cfb0daad upstream.

Commit 4e8ee7de227e3ab9a72040b448ad728c5428a042 (ARM: SMP: use
idmap_pgd for mapping MMU enable during secondary booting)
switched secondary boot to use idmap_pgd, which is initialized
during early_initcall, instead of a page table initialized during
__cpu_up.  This causes idmap_pgd to contain the static mappings
but be missing all dynamic mappings.

If a console is registered that creates a dynamic mapping, the
printk in secondary_start_kernel will trigger a data abort on
the missing mapping before the exception handlers have been
initialized, leading to a hang.  Initial boot is not affected
because no consoles have been registered, and resume is usually
not affected because the offending console is suspended.
Onlining a cpu with hotplug triggers the problem.

A workaround is to the printk in secondary_start_kernel until
after the page tables have been switched back to init_mm.

Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless of endianness 2012-05-12T16:32:15+00:00 Will Deacon will.deacon@arm.com 2012-05-04T16:53:52+00:00 246301f454256967c5845a3e076c05ce488ff910 commit 2f978366984a418f38fcf44137be1fbc5a89cfd9 upstream. The machine endianness has no direct correspondence to the syscall ABI, so use only AUDIT_ARCH_ARM when identifying the ABI to the audit tools in userspace. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2f978366984a418f38fcf44137be1fbc5a89cfd9 upstream.

The machine endianness has no direct correspondence to the syscall ABI,
so use only AUDIT_ARCH_ARM when identifying the ABI to the audit tools
in userspace.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7411/1: audit: fix treatment of saved ip register during syscall tracing 2012-05-12T16:32:09+00:00 Will Deacon will.deacon@arm.com 2012-05-04T16:52:02+00:00 50f764acf24996dc3fd845f837f88a80b80b7d53 commit 6a68b6f574c8ad2c1d90f0db8fd95b8abe8a0a73 upstream. The ARM audit code incorrectly uses the saved application ip register value to infer syscall entry or exit. Additionally, the saved value will be clobbered if the current task is not being traced, which can lead to libc corruption if ip is live (apparently glibc uses it for the TLS pointer). This patch fixes the syscall tracing code so that the why parameter is used to infer the syscall direction and the saved ip is only updated if we know that we will be signalling a ptrace trap. Reported-and-Tested-by: Jon Masters <jcm@jonmasters.org> Cc: Eric Paris <eparis@redhat.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6a68b6f574c8ad2c1d90f0db8fd95b8abe8a0a73 upstream.

The ARM audit code incorrectly uses the saved application ip register
value to infer syscall entry or exit. Additionally, the saved value will
be clobbered if the current task is not being traced, which can lead to
libc corruption if ip is live (apparently glibc uses it for the TLS
pointer).

This patch fixes the syscall tracing code so that the why parameter is
used to infer the syscall direction and the saved ip is only updated if
we know that we will be signalling a ptrace trap.

Reported-and-Tested-by: Jon Masters <jcm@jonmasters.org>

Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: 7410/1: Add extra clobber registers for assembly in kernel_execve 2012-05-12T16:32:05+00:00 Tim Bird tim.bird@am.sony.com 2012-05-02T21:55:39+00:00 acfee6ae4cf54e4afb10252c86dc72ca3472eec7 commit e787ec1376e862fcea1bfd523feb7c5fb43ecdb9 upstream. The inline assembly in kernel_execve() uses r8 and r9. Since this code sequence does not return, it usually doesn't matter if the register clobber list is accurate. However, I saw a case where a particular version of gcc used r8 as an intermediate for the value eventually passed to r9. Because r8 is used in the inline assembly, and not mentioned in the clobber list, r9 was set to an incorrect value. This resulted in a kernel panic on execution of the first user-space program in the system. r9 is used in ret_to_user as the thread_info pointer, and if it's wrong, bad things happen. Signed-off-by: Tim Bird <tim.bird@am.sony.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e787ec1376e862fcea1bfd523feb7c5fb43ecdb9 upstream.

The inline assembly in kernel_execve() uses r8 and r9.  Since this
code sequence does not return, it usually doesn't matter if the
register clobber list is accurate.  However, I saw a case where a
particular version of gcc used r8 as an intermediate for the value
eventually passed to r9.  Because r8 is used in the inline
assembly, and not mentioned in the clobber list, r9 was set
to an incorrect value.

This resulted in a kernel panic on execution of the first user-space
program in the system.  r9 is used in ret_to_user as the thread_info
pointer, and if it's wrong, bad things happen.

Signed-off-by: Tim Bird <tim.bird@am.sony.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>