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

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

xen: drop xen_sched_clock in favour of using plain wallclock time

2010-08-13T20:50:38+00:00

commit 8a22b9996b001c88f2bfb54c6de6a05fc39e177a upstream.

xen_sched_clock only counts unstolen time.  In principle this should
be useful to the Linux scheduler so that it knows how much time a process
actually consumed.  But in practice this doesn't work very well as the
scheduler expects the sched_clock time to be synchronized between
cpus.  It also uses sched_clock to measure the time a task spends
sleeping, in which case "unstolen time" isn't meaningful.

So just use plain xen_clocksource_read to return wallclock nanoseconds
for sched_clock.

Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

.gitignore updates

2010-08-06T17:53:05+00:00

commit c17dad6905fc82d8f523399e5c3f014e81d61df6 upstream.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

x86, Calgary: Limit the max PHB number to 256

2010-08-02T17:18:51+00:00

commit d596043d71ff0d7b3d0bead19b1d68c55f003093 upstream.

The x3950 family can have as many as 256 PCI buses in a single system, so
change the limits to the maximum.  Since there can only be 256 PCI buses in one
domain, we no longer need the BUG_ON check.

Signed-off-by: Darrick J. Wong 
LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com>
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, Calgary: Increase max PHB number

2010-08-02T17:18:50+00:00

commit 499a00e92dd9a75395081f595e681629eb1eebad upstream.

Newer systems (x3950M2) can have 48 PHBs per chassis and 8
chassis, so bump the limits up and provide an explanation
of the requirements for each class.

Signed-off-by: Darrick J. Wong 
Acked-by: Muli Ben-Yehuda 
Cc: Corinna Schultz 
LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com>
[ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

parisc: clear floating point exception flag on SIGFPE signal

2010-07-05T18:08:47+00:00

commit 550f0d922286556c7ea43974bb7921effb5a5278 upstream.

Clear the floating point exception flag before returning to
user space. This is needed, else the libc trampoline handler
may hit the same SIGFPE again while building up a trampoline
to a signal handler.

Fixes debian bug #559406.

Signed-off-by: Helge Deller 
Signed-off-by: Kyle McMartin 
Signed-off-by: Greg Kroah-Hartman