linux-stable.git/arch/arm, branch v3.0.35

ARM: 7409/1: Do not call flush_cache_user_range with mmap_sem held

2012-06-01T07:13:01+00:00

commit 435a7ef52db7d86e67a009b36cac1457f8972391 upstream.

We can't be holding the mmap_sem while calling flush_cache_user_range
because the flush can fault. If we fault on a user address, the
page fault handler will try to take mmap_sem again. Since both places
acquire the read lock, most of the time it succeeds. However, if another
thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in
between the call to flush_cache_user_range and the fault, the down_read
in do_page_fault will deadlock.

[will: removed drop of vma parameter as already queued by rmk (7365/1)]

Acked-by: Catalin Marinas 
Signed-off-by: Dima Zavin 
Signed-off-by: John Stultz 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7365/1: drop unused parameter from flush_cache_user_range

2012-06-01T07:13:00+00:00

commit 4542b6a0fa6b48d9ae6b41c1efeb618b7a221b2a upstream.

vma isn't used and flush_cache_user_range isn't a standard macro that
is used on several archs with the same prototype. In fact only unicore32
has a macro with the same name (with an identical implementation and no
in-tree users).

This is a part of a patch proposed by Dima Zavin (with Message-id:
1272439931-12795-1-git-send-email-dima@android.com) that didn't get
accepted.

Cc: Dima Zavin 
Acked-by: Catalin Marinas 
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Russell King 
Cc: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS

2012-05-21T16:40:01+00:00

commit 9b61a4d1b2064dbd0c9e61754305ac852170509f upstream.

Reported-by: Al Viro 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: orion5x: Fix GPIO enable bits for MPP9

2012-05-21T16:39:58+00:00

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 
References: http://bugs.debian.org/667446
Signed-off-by: Ben Hutchings 
Tested-by: Hans Henry von Tresckow 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: 7414/1: SMP: prevent use of the console when using idmap_pgd

2012-05-21T16:39:58+00:00

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 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7410/1: Add extra clobber registers for assembly in kernel_execve

2012-05-21T16:39:58+00:00

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 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7403/1: tls: remove covert channel via TPIDRURW

2012-05-07T15:56:37+00:00

commit 6a1c53124aa161eb624ce7b1e40ade728186d34c upstream.

TPIDRURW is a user read/write register forming part of the group of
thread registers in more recent versions of the ARM architecture (~v6+).

Currently, the kernel does not touch this register, which allows tasks
to communicate covertly by reading and writing to the register without
context-switching affecting its contents.

This patch clears TPIDRURW when TPIDRURO is updated via the set_tls
macro, which is called directly from __switch_to. Since the current
behaviour makes the register useless to userspace as far as thread
pointers are concerned, simply clearing the register (rather than saving
and restoring it) will not cause any problems to userspace.

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-22T23:21:22+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-03-12T17:32:59+00:00

commit efbc74ace95338484f8d732037b99c7c77098fce upstream.

Erratum #743622 affects all r2 variants of the Cortex-A9 processor, so
ensure that the workaround is applied regardless of the revision.

Reported-by: Russell King 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

OMAPDSS: HDMI: PHY burnout fix

2012-03-12T17:32:59+00:00

commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd upstream.

A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.

This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.

The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.

The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
"ticking" and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman