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

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

2012-05-12T16:32:17+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: 7412/1: audit: use only AUDIT_ARCH_ARM regardless of endianness

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

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

ARM: 7411/1: audit: fix treatment of saved ip register during syscall tracing

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

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 

Cc: Eric Paris 
Signed-off-by: Will Deacon 
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-12T16:32:05+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: 7406/1: hotplug: copy the affinity mask when forcefully migrating IRQs

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

commit 5e7371ded05adfcfcee44a8bc070bfc37979b8f2 upstream.

When a CPU is hotplugged off, we migrate any IRQs currently affine to it
away and onto another online CPU by calling the irq_set_affinity
function of the relevant interrupt controller chip. This function
returns either IRQ_SET_MASK_OK or IRQ_SET_MASK_OK_NOCOPY, to indicate
whether irq_data.affinity was updated.

If we are forcefully migrating an interrupt (because the affinity mask
no longer identifies any online CPUs) then we should update the IRQ
affinity mask to reflect the new CPU set. Failure to do so can
potentially leave /proc/irq/n/smp_affinity identifying only offline
CPUs, which may confuse userspace IRQ balancing daemons.

This patch updates migrate_one_irq to copy the affinity mask when
the interrupt chip returns IRQ_SET_MASK_OK after forcefully changing the
affinity of an interrupt.

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

ARM: 7358/1: perf: add PMU hotplug notifier

2012-03-07T09:40:50+00:00

When a CPU is taken out of reset, either cold booted or hotplugged in,
some of its PMU registers can contain UNKNOWN values.

This patch adds a hotplug notifier to ARM core perf code so that upon
CPU restart the PMU unit is reset and becomes ready to use again.

Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: 7357/1: perf: fix overflow handling for xscale2 PMUs

2012-03-07T09:40:49+00:00

xscale2 PMUs indicate overflow not via the PMU control register, but by
a separate overflow FLAG register instead.

This patch fixes the xscale2 PMU code to use this register to detect
to overflow and ensures that we clear any pending overflow when
disabling a counter.

Cc: 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: 7356/1: perf: check that we have an event in the PMU IRQ handlers

2012-03-07T09:40:49+00:00

The PMU IRQ handlers in perf assume that if a counter has overflowed
then perf must be responsible. In the paranoid world of crazy hardware,
this could be false, so check that we do have a valid event before
attempting to dereference NULL in the interrupt path.

Cc: 
Signed-off-by: Ming Lei 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: 7355/1: perf: clear overflow flag when disabling counter on ARMv7 PMU

2012-03-07T09:40:49+00:00

When disabling a counter on an ARMv7 PMU, we should also clear the
overflow flag in case an overflow occurred whilst stopping the counter.
This prevents a spurious overflow being picked up later and leading to
either false accounting or a NULL dereference.

Cc: 
Reported-by: Ming Lei 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: 7354/1: perf: limit sample_period to half max_period in non-sampling mode

2012-03-07T09:40:48+00:00

On ARM, the PMU does not stop counting after an overflow and therefore
IRQ latency affects the new counter value read by the kernel. This is
significant for non-sampling runs where it is possible for the new value
to overtake the previous one, causing the delta to be out by up to
max_period events.

Commit a737823d ("ARM: 6835/1: perf: ensure overflows aren't missed due
to IRQ latency") attempted to fix this problem by allowing interrupt
handlers to pass an overflow flag to the event update function, causing
the overflow calculation to assume that the counter passed through zero
when going from prev to new. Unfortunately, this doesn't work when
overflow occurs on the perf_task_tick path because we have the flag
cleared and end up computing a large negative delta.

This patch removes the overflow flag from armpmu_event_update and
instead limits the sample_period to half of the max_period for
non-sampling profiling runs.

Cc: 
Signed-off-by: Ming Lei 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King