linux-toradex.git/arch, branch v2.6.27.57

ARM: 6482/2: Fix find_next_zero_bit and related assembly

2010-12-09T21:24:19+00:00

commit 0e91ec0c06d2cd15071a6021c94840a50e6671aa upstream.

The find_next_bit, find_first_bit, find_next_zero_bit
and find_first_zero_bit functions were not properly
clamping to the maxbit argument at the bit level. They
were instead only checking maxbit at the byte level.
To fix this, add a compare and a conditional move
instruction to the end of the common bit-within-the-
byte code used by all the functions and be sure not to
clobber the maxbit argument before it is used.

Reviewed-by: Nicolas Pitre 
Tested-by: Stephen Warren 
Signed-off-by: James Jones 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

acpi-cpufreq: fix a memleak when unloading driver

2010-12-09T21:24:19+00:00

commit dab5fff14df2cd16eb1ad4c02e83915e1063fece upstream.

We didn't free per_cpu(acfreq_data, cpu)->freq_table
when acpi_freq driver is unloaded.

Resulting in the following messages in /sys/kernel/debug/kmemleak:

unreferenced object 0xf6450e80 (size 64):
  comm "modprobe", pid 1066, jiffies 4294677317 (age 19290.453s)
  hex dump (first 32 bytes):
    00 00 00 00 e8 a2 24 00 01 00 00 00 00 9f 24 00  ......$.......$.
    02 00 00 00 00 6a 18 00 03 00 00 00 00 35 0c 00  .....j.......5..
  backtrace:
    [] kmemleak_alloc+0x27/0x50
    [] __kmalloc+0xcf/0x110
    [] acpi_cpufreq_cpu_init+0x1ee/0x4e4 [acpi_cpufreq]
    [] cpufreq_add_dev+0x142/0x3a0
    [] sysdev_driver_register+0x97/0x110
    [] cpufreq_register_driver+0x86/0x140
    [] 0xf9dad080
    [] do_one_initcall+0x30/0x160
    [] sys_init_module+0x99/0x1e0
    [] sysenter_do_call+0x12/0x26
    [] 0xffffffff

https://bugzilla.kernel.org/show_bug.cgi?id=15807#c21

Tested-by: Toralf Forster 
Signed-off-by: Zhang Rui 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

um: fix global timer issue when using CONFIG_NO_HZ

2010-12-09T21:24:16+00:00

commit 482db6df1746c4fa7d64a2441d4cb2610249c679 upstream.

This fixes a issue which was introduced by fe2cc53e ("uml: track and make
up lost ticks").

timeval_to_ns() returns long long and not int.  Due to that UML's timer
did not work properlt and caused timer freezes.

Signed-off-by: Richard Weinberger 
Acked-by: Pekka Enberg 
Cc: Jeff Dike 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

powerpc: Don't use kernel stack with translation off

2010-10-29T04:04:17+00:00

commit 54a834043314c257210db2a9d59f8cc605571639 upstream.

In f761622e59433130bc33ad086ce219feee9eb961 we changed
early_setup_secondary so it's called using the proper kernel stack
rather than the emergency one.

Unfortunately, this stack pointer can't be used when translation is off
on PHYP as this stack pointer might be outside the RMO.  This results in
the following on all non zero cpus:
  cpu 0x1: Vector: 300 (Data Access) at [c00000001639fd10]
      pc: 000000000001c50c
      lr: 000000000000821c
      sp: c00000001639ff90
     msr: 8000000000001000
     dar: c00000001639ffa0
   dsisr: 42000000
    current = 0xc000000016393540
    paca    = 0xc000000006e00200
      pid   = 0, comm = swapper

The original patch was only tested on bare metal system, so it never
caught this problem.

This changes __secondary_start so that we calculate the new stack
pointer but only start using it after we've called early_setup_secondary.

With this patch, the above problem goes away.

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc: Initialise paca->kstack before early_setup_secondary

2010-10-29T04:04:17+00:00

commit f761622e59433130bc33ad086ce219feee9eb961 upstream.

As early setup calls down to slb_initialize(), we must have kstack
initialised before checking "should we add a bolted SLB entry for our kstack?"

Failing to do so means stack access requires an SLB miss exception to refill
an entry dynamically, if the stack isn't accessible via SLB(0) (kernel text
& static data).  It's not always allowable to take such a miss, and
intermittent crashes will result.

Primary CPUs don't have this issue; an SLB entry is not bolted for their
stack anyway (as that lives within SLB(0)).  This patch therefore only
affects the init of secondaries.

Signed-off-by: Matt Evans 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

x86-64, compat: Retruncate rax after ia32 syscall entry tracing

2010-09-20T20:03:22+00:00

commit eefdca043e8391dcd719711716492063030b55ac upstream.

In commit d4d6715, we reopened an old hole for a 64-bit ptracer touching a
32-bit tracee in system call entry.  A %rax value set via ptrace at the
entry tracing stop gets used whole as a 32-bit syscall number, while we
only check the low 32 bits for validity.

Fix it by truncating %rax back to 32 bits after syscall_trace_enter,
in addition to testing the full 64 bits as has already been added.

Reported-by: Ben Hawkes 
Signed-off-by: Roland McGrath 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

compat: Make compat_alloc_user_space() incorporate the access_ok()

2010-09-20T20:03:21+00:00

commit c41d68a513c71e35a14f66d71782d27a79a81ea6 upstream.

compat_alloc_user_space() expects the caller to independently call
access_ok() to verify the returned area.  A missing call could
introduce problems on some architectures.

This patch incorporates the access_ok() check into
compat_alloc_user_space() and also adds a sanity check on the length.
The existing compat_alloc_user_space() implementations are renamed
arch_compat_alloc_user_space() and are used as part of the
implementation of the new global function.

This patch assumes NULL will cause __get_user()/__put_user() to either
fail or access userspace on all architectures.  This should be
followed by checking the return value of compat_access_user_space()
for NULL in the callers, at which time the access_ok() in the callers
can also be removed.

Reported-by: Ben Hawkes 
Signed-off-by: H. Peter Anvin 
Acked-by: Benjamin Herrenschmidt 
Acked-by: Chris Metcalf 
Acked-by: David S. Miller 
Acked-by: Ingo Molnar 
Acked-by: Thomas Gleixner 
Acked-by: Tony Luck 
Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Heiko Carstens 
Cc: Helge Deller 
Cc: James Bottomley 
Cc: Kyle McMartin 
Cc: Martin Schwidefsky 
Cc: Paul Mackerras 
Cc: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

x86-64, compat: Test %rax for the syscall number, not %eax

2010-09-20T20:03:21+00:00

commit 36d001c70d8a0144ac1d038f6876c484849a74de upstream.

On 64 bits, we always, by necessity, jump through the system call
table via %rax.  For 32-bit system calls, in theory the system call
number is stored in %eax, and the code was testing %eax for a valid
system call number.  At one point we loaded the stored value back from
the stack to enforce zero-extension, but that was removed in checkin
d4d67150165df8bf1cc05e532f6efca96f907cab.  An actual 32-bit process
will not be able to introduce a non-zero-extended number, but it can
happen via ptrace.

Instead of re-introducing the zero-extension, test what we are
actually going to use, i.e. %rax.  This only adds a handful of REX
prefixes to the code.

Reported-by: Ben Hawkes 
Signed-off-by: H. Peter Anvin 
Cc: Roland McGrath 
Cc: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

ARM: Tighten check for allowable CPSR values

2010-08-26T23:40:11+00:00

commit 41e2e8fd34fff909a0e40129f6ac4233ecfa67a9 upstream.

Reviewed-by: Arve Hjønnevåg 
Acked-by: Dima Zavin 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

x86: don't send SIGBUS for kernel page faults

2010-08-20T18:25:11+00:00

Based on commit 96054569190bdec375fe824e48ca1f4e3b53dd36 upstream,
authored by Linus Torvalds.

This is my backport to the .27 kernel tree, hopefully preserving
the same functionality.

Original commit message:
	It's wrong for several reasons, but the most direct one is that the
	fault may be for the stack accesses to set up a previous SIGBUS.  When
	we have a kernel exception, the kernel exception handler does all the
	fixups, not some user-level signal handler.

	Even apart from the nested SIGBUS issue, it's also wrong to give out
	kernel fault addresses in the signal handler info block, or to send a
	SIGBUS when a system call already returns EFAULT.

Cc: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman