linux-toradex.git/arch, branch v3.3.3

fix tlb flushing for page table pages

2012-04-22T22:39:16+00:00

commit cd94154cc6a28dd9dc271042c1a59c08d26da886 upstream.

Git commit 36409f6353fc2d7b6516e631415f938eadd92ffa "use generic RCU
page-table freeing code" introduced a tlb flushing bug. Partially revert
the above git commit and go back to s390 specific page table flush code.

For s390 the TLB can contain three types of entries, "normal" TLB
page-table entries, TLB combined region-and-segment-table (CRST) entries
and real-space entries. Linux does not use real-space entries which
leaves normal TLB entries and CRST entries. The CRST entries are
intermediate steps in the page-table translation called translation paths.
For example a 4K page access in a three-level page table setup will
create two CRST TLB entries and one page-table TLB entry. The advantage
of that approach is that a page access next to the previous one can reuse
the CRST entries and needs just a single read from memory to create the
page-table TLB entry. The disadvantage is that the TLB flushing rules are
more complicated, before any page-table may be freed the TLB needs to be
flushed.

In short: the generic RCU page-table freeing code is incorrect for the
CRST entries, in particular the check for mm_users < 2 is troublesome.

This is applicable to 3.0+ kernels.

Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

x86: Use correct byte-sized register constraint in __add()

2012-04-22T22:38:59+00:00

commit 8c91c5325e107ec17e40a59a47c6517387d64eb7 upstream.

Similar to:

 2ca052a x86: Use correct byte-sized register constraint in __xchg_op()

... the __add() macro also needs to use a "q" constraint in the
byte-sized case, lest we try to generate an illegal register.

Link: http://lkml.kernel.org/r/4F7A3315.501@goop.org
Signed-off-by: H. Peter Anvin 
Cc: Jeremy Fitzhardinge 
Cc: Leigh Scott 
Cc: Thomas Reitmayr 
Signed-off-by: Greg Kroah-Hartman

x86: Use correct byte-sized register constraint in __xchg_op()

2012-04-22T22:38:59+00:00

commit 2ca052a3710fac208eee690faefdeb8bbd4586a1 upstream.

x86-64 can access the low half of any register, but i386 can only do
it with a subset of registers.  'r' causes compilation failures on i386,
but 'q' expresses the constraint properly.

Signed-off-by: Jeremy Fitzhardinge 
Link: http://lkml.kernel.org/r/4F7A3315.501@goop.org
Reported-by: Leigh Scott 
Tested-by: Thomas Reitmayr 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix bootup crash on sun4v.

2012-04-22T22:38:58+00:00

commit 9e0daff30fd7ecf698e5d20b0fa7f851e427cca5 upstream.

The DS driver registers as a subsys_initcall() but this can be too
early, in particular this risks registering before we've had a chance
to allocate and setup module_kset in kernel/params.c which is
performed also as a subsyts_initcall().

Register DS using device_initcall() insteal.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Eliminate obsolete __handle_softirq() function

2012-04-22T22:38:58+00:00

commit 3d3eeb2ef26112a200785e5fca58ec58dd33bf1e upstream.

The invocation of softirq is now handled by irq_exit(), so there is no
need for sparc64 to invoke it on the trap-return path.  In fact, doing so
is a bug because if the trap occurred in the idle loop, this invocation
can result in lockdep-RCU failures.  The problem is that RCU ignores idle
CPUs, and the sparc64 trap-return path to the softirq handlers fails to
tell RCU that the CPU must be considered non-idle while those handlers
are executing.  This means that RCU is ignoring any RCU read-side critical
sections in those handlers, which in turn means that RCU-protected data
can be yanked out from under those read-side critical sections.

The shiny new lockdep-RCU ability to detect RCU read-side critical sections
that RCU is ignoring located this problem.

The fix is straightforward: Make sparc64 stop manually invoking the
softirq handlers.

Reported-by: Meelis Roos 
Suggested-by: David Miller 
Signed-off-by: Paul E. McKenney 
Tested-by: Meelis Roos 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ia64: fix futex_atomic_cmpxchg_inatomic()

2012-04-22T22:38:56+00:00

commit c76f39bddb84f93f70a5520d9253ec0317bec216 upstream.

Michel Lespinasse cleaned up the futex calling conventions in commit
37a9d912b24f ("futex: Sanitize cmpxchg_futex_value_locked API").

But the ia64 implementation was subtly broken.  Gcc does not know that
register "r8" will be updated by the fault handler if the cmpxchg
instruction takes an exception.  So it feels safe in letting the
initialization of r8 slide to after the cmpxchg.  Result: we always
return 0 whether the user address faulted or not.

Fix by moving the initialization of r8 into the __asm__ code so gcc
won't move it.

Reported-by: 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42757
Tested-by: 
Acked-by: Michel Lespinasse 
Signed-off-by: Tony Luck 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE

2012-04-22T22:38:55+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: 7379/1: DT: fix atags_to_fdt() second call site

2012-04-22T22:38:54+00:00

commit 9c5fd9e85f574d9d0361b2b878f55732290afe5b upstream.

atags_to_fdt() returns 1 when it fails to find a valid FDT signature.
The CONFIG_ARM_ATAG_DTB_COMPAT code is supposed to retry with another
location, but only does so when the initial call doesn't fail.

Fix this by using the correct condition in the assembly code.

Acked-by: Nicolas Pitre 
Signed-off-by: Marc Zyngier 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

sched/x86: Fix overflow in cyc2ns_offset

2012-04-13T16:13:56+00:00

commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 upstream.

When a machine boots up, the TSC generally gets reset.  However,
when kexec is used to boot into a kernel, the TSC value would be
carried over from the previous kernel.  The computation of
cycns_offset in set_cyc2ns_scale is prone to an overflow, if the
machine has been up more than 208 days prior to the kexec.  The
overflow happens when we multiply *scale, even though there is
enough room to store the final answer.

We fix this issue by decomposing tsc_now into the quotient and
remainder of division by CYC2NS_SCALE_FACTOR and then performing
the multiplication separately on the two components.

Refactor code to share the calculation with the previous
fix in __cycles_2_ns().

Signed-off-by: Salman Qazi 
Acked-by: John Stultz 
Acked-by: Peter Zijlstra 
Cc: Paul Turner 
Cc: john stultz 
Link: http://lkml.kernel.org/r/20120310004027.19291.88460.stgit@dungbeetle.mtv.corp.google.com
Signed-off-by: Ingo Molnar 
Cc: Mike Galbraith 
Signed-off-by: Greg Kroah-Hartman

Revert "x86/ioapic: Add register level checks to detect bogus io-apic entries"

2012-04-13T16:13:56+00:00

This reverts commit a998dc2fa76f496d2944f0602b920d1d10d7467d
[73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream]

It causes problems, so needs to be reverted from 3.2-stable for now.

Reported-by: Konrad Rzeszutek Wilk 
Cc: Jon Dufresne 
Cc: Suresh Siddha 
Cc: 
Cc: Josh Boyer 
Cc: Ingo Molnar 
Cc: Teck Choon Giam 
Cc: Ben Guthro 
Signed-off-by: Greg Kroah-Hartman