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

arm: fix really nasty sigreturn bug

2010-09-20T20:18:12+00:00

commit 653d48b22166db2d8b1515ebe6f9f0f7c95dfc86 upstream.

If a signal hits us outside of a syscall and another gets delivered
when we are in sigreturn (e.g. because it had been in sa_mask for
the first one and got sent to us while we'd been in the first handler),
we have a chance of returning from the second handler to location one
insn prior to where we ought to return.  If r0 happens to contain -513
(-ERESTARTNOINTR), sigreturn will get confused into doing restart
syscall song and dance.

Incredible joy to debug, since it manifests as random, infrequent and
very hard to reproduce double execution of instructions in userland
code...

The fix is simple - mark it "don't bother with restarts" in wrapper,
i.e. set r8 to 0 in sys_sigreturn and sys_rt_sigreturn wrappers,
suppressing the syscall restart handling on return from these guys.
They can't legitimately return a restart-worthy error anyway.

Testcase:
	#include 
	#include 
	#include 
	#include 
	#include 

	void f(int n)
	{
		__asm__ __volatile__(
			"ldr r0, [%0]\n"
			"b 1f\n"
			"b 2f\n"
			"1:b .\n"
			"2:\n" : : "r"(&n));
	}

	void handler1(int sig) { }
	void handler2(int sig) { raise(1); }
	void handler3(int sig) { exit(0); }

	main()
	{
		struct sigaction s = {.sa_handler = handler2};
		struct itimerval t1 = { .it_value = {1} };
		struct itimerval t2 = { .it_value = {2} };

		signal(1, handler1);

		sigemptyset(&s.sa_mask);
		sigaddset(&s.sa_mask, 1);
		sigaction(SIGALRM, &s, NULL);

		signal(SIGVTALRM, handler3);

		setitimer(ITIMER_REAL, &t1, NULL);
		setitimer(ITIMER_VIRTUAL, &t2, NULL);

		f(-513); /* -ERESTARTNOINTR */

		write(1, "buggered\n", 9);
		return 1;
	}

Signed-off-by: Al Viro 
Acked-by: Russell King 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

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

2010-09-20T20:17:57+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:17:57+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:17:56+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

x86, tsc: Fix a preemption leak in restore_sched_clock_state()

2010-09-20T20:17:56+00:00

commit 55496c896b8a695140045099d4e0175cf09d4eae upstream.

Doh, a real life genuine preemption leak..

This caused a suspend failure.

Reported-bisected-and-tested-by-the-invaluable: Jeff Chua 
Acked-by: Suresh Siddha 
Signed-off-by: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Nico Schottelius 
Cc: Jesse Barnes 
Cc: Linus Torvalds 
Cc: Florian Pritz 
Cc: Suresh Siddha 
Cc: Len Brown 
sleep states
LKML-Reference: <1284150773.402.122.camel@laptop>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

oprofile, x86: fix init_sysfs() function stub

2010-09-20T20:17:51+00:00

commit 269f45c25028c75fe10e6d9be86e7202ab461fbc upstream.

The use of the return value of init_sysfs() with commit

 10f0412 oprofile, x86: fix init_sysfs error handling

discovered the following build error for !CONFIG_PM:

 .../linux/arch/x86/oprofile/nmi_int.c: In function ‘op_nmi_init’:
 .../linux/arch/x86/oprofile/nmi_int.c:784: error: expected expression before ‘do’
 make[2]: *** [arch/x86/oprofile/nmi_int.o] Error 1
 make[1]: *** [arch/x86/oprofile] Error 2

This patch fixes this.

Reported-by: Ingo Molnar 
Signed-off-by: Robert Richter 
Signed-off-by: Greg Kroah-Hartman

oprofile, x86: fix init_sysfs error handling

2010-09-20T20:17:50+00:00

commit 10f0412f57f2a76a90eff4376f59cbb0a39e4e18 upstream.

On failure init_sysfs() might not properly free resources. The error
code of the function is not checked. And, when reinitializing the exit
function might be called twice. This patch fixes all this.

Signed-off-by: Robert Richter 
Signed-off-by: Greg Kroah-Hartman

PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()

2010-09-20T20:17:44+00:00

commit 30da55242818a8ca08583188ebcbaccd283ad4d9 upstream.

commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove
unsafe and unnecessary hardware access" changed read_msi_msg_desc() to
return the last MSI message written instead of reading it from the
device, since it may be called while the device is in a reduced
power state.

However, the pSeries platform code really does need to read messages
from the device, since they are initially written by firmware.
Therefore:
- Restore the previous behaviour of read_msi_msg_desc()
- Add new functions get_cached_msi_msg{,_desc}() which return the
  last MSI message written
- Use the new functions where appropriate

Acked-by: Michael Ellerman 
Signed-off-by: Ben Hutchings 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

x86, tsc, sched: Recompute cyc2ns_offset's during resume from sleep states

2010-09-20T20:17:44+00:00

commit cd7240c0b900eb6d690ccee088a6c9b46dae815a upstream.

TSC's get reset after suspend/resume (even on cpu's with invariant TSC
which runs at a constant rate across ACPI P-, C- and T-states). And in
some systems BIOS seem to reinit TSC to arbitrary large value (still
sync'd across cpu's) during resume.

This leads to a scenario of scheduler rq->clock (sched_clock_cpu()) less
than rq->age_stamp (introduced in 2.6.32). This leads to a big value
returned by scale_rt_power() and the resulting big group power set by the
update_group_power() is causing improper load balancing between busy and
idle cpu's after suspend/resume.

This resulted in multi-threaded workloads (like kernel-compilation) go
slower after suspend/resume cycle on core i5 laptops.

Fix this by recomputing cyc2ns_offset's during resume, so that
sched_clock() continues from the point where it was left off during
suspend.

Reported-by: Florian Pritz 
Signed-off-by: Suresh Siddha 
Signed-off-by: Peter Zijlstra 
LKML-Reference: <1282262618.2675.24.camel@sbsiddha-MOBL3.sc.intel.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, apic: ack all pending irqs when crashed/on kexec

2010-08-26T23:42:00+00:00

commit 8c3ba8d049247dc06b6dcee1711a11b26647aa44 upstream.

When the SMP kernel decides to crash_kexec() the local APICs may have
pending interrupts in their vector tables.

The setup routine for the local APIC has a deficient mechanism for
clearing these interrupts, it only handles interrupts that has already
been dispatched to the local core for servicing (the ISR register) safely,
it doesn't consider lower prioritized queued interrupts stored in the IRR
register.

If you have more than one pending interrupt within the same 32 bit word in
the LAPIC vector table registers you may find yourself entering the IO
APIC setup with pending interrupts left in the LAPIC.  This is a situation
for wich the IO APIC setup is not prepared.  Depending of what/which
interrupt vector/vectors are stuck in the APIC tables your system may show
various degrees of malfunctioning.  That was the reason why the
check_timer() failed in our system, the timer interrupts was blocked by
pending interrupts from the old kernel when routed trough the IO APIC.

Additional comment from Jiri Bohac:
==============
If this should go into stable release,
I'd add some kind of limit on the number of iterations, just to be safe from
hard to debug lock-ups:

+if (loops++  > MAX_LOOPS) {
+        printk("LAPIC pending clean-up")
+        break;
+}
 while (queued);

with MAX_LOOPS something like 1E9 this would leave plenty of time for the
pending IRQs to be cleared and would and still cause at most a second of delay
if the loop were to lock-up for whatever reason.

[trenn@suse.de:

V2: Use tsc if avail to bail out after 1 sec due to possible virtual
    apic_read calls which may take rather long (suggested by: Avi Kivity
    ) If no tsc is available bail out quickly after
    cpu_khz, if we broke out too early and still have irqs pending (which
    should never happen?) we still get a WARN_ON...

V3: - Fixed indentation -> checkpatch clean
    - max_loops must be signed

V4: - Fix typo, mixed up tsc and ntsc in first rdtscll() call

V5: Adjust WARN_ON() condition to also catch error in cpu_has_tsc case]

Cc: 
Cc: Yinghai Lu 
Cc: Kerstin Jonsson 
Cc: Avi Kivity 
Cc: Suresh Siddha 
Tested-by: Eric W. Biederman 
Signed-off-by: Thomas Renninger 
LKML-Reference: <201005241913.o4OJDGWM010865@imap1.linux-foundation.org>
Signed-off-by: Andrew Morton 
Signed-off-by: H. Peter Anvin 
Cc: Thomas Renninger 
Signed-off-by: Greg Kroah-Hartman