linux-stable.git/arch, branch linux-3.7.y

sparc64: Fix huge PMD to PTE translation for sun4u in TLB miss handler.

2013-02-27T17:21:14+00:00

[ Upstream commit 76968ad2eac6456270353de168b21f04f4b3d1d3 ]

When we set the sun4u version of the PTE execute bit, it's:

	or	REG, _PAGE_EXEC_4U, REG

_PAGE_EXEC_4U is 0x1000, unfortunately the immedate field of the
'or' instruction is a signed 13-bit value.  So the above actually
assembles into:

	or	REG, -4096, REG

completely corrupting the final PTE value.

Set it with a:

	sethi	%hi(_PAGE_EXEC_4U), TMP
	or	REG, TMP, REG

sequence instead.

This fixes "git gc" crashes on sun4u machines.

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

sparc64: Fix tsb_grow() in atomic context.

2013-02-27T17:21:12+00:00

[ Upstream commit 0fbebed682ff2788dee58e8d7f7dda46e33aa10b ]

If our first THP installation for an MM is via the set_pmd_at() done
during khugepaged's collapsing we'll end up in tsb_grow() trying to do
a GFP_KERNEL allocation with several locks held.

Simply using GFP_ATOMIC in this situation is not the best option
because we really can't have this fail, so we'd really like to keep
this an order 0 GFP_KERNEL allocation if possible.

Also, doing the TSB allocation from khugepaged is a really bad idea
because we'll allocate it potentially from the wrong NUMA node in that
context.

So what we do is defer the hugepage TSB allocation until the first TLB
miss we take on a hugepage.  This is slightly tricky because we have
to handle two unusual cases:

1) Taking the first hugepage TLB miss in the window trap handler.
   We'll call the winfix_trampoline when that is detected.

2) An initial TSB allocation via TLB miss races with a hugetlb
   fault on another cpu running the same MM.  We handle this by
   unconditionally loading the TSB we see into the current cpu
   even if it's non-NULL at hugetlb_setup time.

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

sparc64: Handle hugepage TSB being NULL.

2013-02-27T17:21:12+00:00

[ Upstream commit bcd896bae0166b4443503482a26ecf84d9ba60ab ]

Accomodate the possibility that the TSB might be NULL at
the point that update_mmu_cache() is invoked.  This is
necessary because we will sometimes need to defer the TSB
allocation to the first fault that happens in the 'mm'.

Seperate out the hugepage PTE test into a seperate function
so that the logic is clearer.

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

sparc64: Fix gfp_flags setting in tsb_grow().

2013-02-27T17:21:12+00:00

[ Upstream commit a55ee1ff751f88252207160087d8197bb7538d4c ]

We should "|= more_flags" rather than "= more_flags".

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

sparc64: Fix get_user_pages_fast() wrt. THP.

2013-02-27T17:21:12+00:00

[ Upstream commit 89a77915e0f56dc7b9f9082ba787895b6a83f809 ]

Mostly mirrors the s390 logic, as unlike x86 we don't need the
SetPageReferenced() bits.

On sparc64 we also lack a user/privileged bit in the huge PMDs.

In order to make this work for THP and non-THP builds, some header
file adjustments were necessary.  Namely, provide the PMD_HUGE_* bit
defines and the pmd_large() inline unconditionally rather than
protected by TRANSPARENT_HUGEPAGE.

Reported-by: Aneesh Kumar K.V 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Add missing HAVE_ARCH_TRANSPARENT_HUGEPAGE.

2013-02-27T17:21:11+00:00

[ Upstream commit b9156ebb7beef015745f917f373abc137efc3400 ]

This got missed in the cleanups done for the S390 THP
support.

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

s390/kvm: Fix store status for ACRS/FPRS

2013-02-27T17:21:08+00:00

commit 15bc8d8457875f495c59d933b05770ba88d1eacb upstream.

On store status we need to copy the current state of registers
into a save area. Currently we might save stale versions:
The sie state descriptor doesnt have fields for guest ACRS,FPRS,
those registers are simply stored in the host registers. The host
program must copy these away if needed. We do that in vcpu_put/load.

If we now do a store status in KVM code between vcpu_put/load, the
saved values are not up-to-date. Lets collect the ACRS/FPRS before
saving them.

This also fixes some strange problems with hotplug and virtio-ccw,
since the low level machine check handler (on hotplug a machine check
will happen) will revalidate all registers with the content of the
save area.

Signed-off-by: Christian Borntraeger 
Signed-off-by: Gleb Natapov 
Signed-off-by: Greg Kroah-Hartman

xen: Send spinlock IPI to all waiters

2013-02-27T17:21:07+00:00

commit 76eaca031f0af2bb303e405986f637811956a422 upstream.

There is a loophole between Xen's current implementation of
pv-spinlocks and the scheduler. This was triggerable through
a testcase until v3.6 changed the TLB flushing code. The
problem potentially is still there just not observable in the
same way.

What could happen was (is):

1. CPU n tries to schedule task x away and goes into a slow
   wait for the runq lock of CPU n-# (must be one with a lower
   number).
2. CPU n-#, while processing softirqs, tries to balance domains
   and goes into a slow wait for its own runq lock (for updating
   some records). Since this is a spin_lock_irqsave in softirq
   context, interrupts will be re-enabled for the duration of
   the poll_irq hypercall used by Xen.
3. Before the runq lock of CPU n-# is unlocked, CPU n-1 receives
   an interrupt (e.g. endio) and when processing the interrupt,
   tries to wake up task x. But that is in schedule and still
   on_cpu, so try_to_wake_up goes into a tight loop.
4. The runq lock of CPU n-# gets unlocked, but the message only
   gets sent to the first waiter, which is CPU n-# and that is
   busily stuck.
5. CPU n-# never returns from the nested interruption to take and
   release the lock because the scheduler uses a busy wait.
   And CPU n never finishes the task migration because the unlock
   notification only went to CPU n-#.

To avoid this and since the unlocking code has no real sense of
which waiter is best suited to grab the lock, just send the IPI
to all of them. This causes the waiters to return from the hyper-
call (those not interrupted at least) and do active spinlocking.

BugLink: http://bugs.launchpad.net/bugs/1011792

Acked-by: Jan Beulich 
Signed-off-by: Stefan Bader 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

x86: Hyper-V: register clocksource only if its advertised

2013-02-27T17:20:55+00:00

commit 32068f6527b8f1822a30671dedaf59c567325026 upstream.

Enable hyperv_clocksource only if its advertised as a feature.
XenServer 6 returns the signature which is checked in
ms_hyperv_platform(), but it does not offer all features. Currently the
clocksource is enabled unconditionally in ms_hyperv_init_platform(), and
the result is a hanging guest.

Hyper-V spec Bit 1 indicates the availability of Partition Reference
Counter.  Register the clocksource only if this bit is set.

The guest in question prints this in dmesg:
 [    0.000000] Hypervisor detected: Microsoft HyperV
 [    0.000000] HyperV: features 0x70, hints 0x0

This bug can be reproduced easily be setting 'viridian=1' in a HVM domU
.cfg file. A workaround without this patch is to boot the HVM guest with
'clocksource=jiffies'.

Signed-off-by: Olaf Hering 
Link: http://lkml.kernel.org/r/1359940959-32168-1-git-send-email-kys@microsoft.com
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86-32, mm: Remove reference to alloc_remap()

2013-02-27T17:20:53+00:00

commit 07f4207a305c834f528d08428df4531744e25678 upstream.

We have removed the remap allocator for x86-32, and x86-64 never had
it (and doesn't need it).  Remove residual reference to it.

Reported-by: Yinghai Lu 
Signed-off-by: H. Peter Anvin 
Cc: Dave Hansen 
Link: http://lkml.kernel.org/r/CAE9FiQVn6_QZi3fNQ-JHYiR-7jeDJ5hT0SyT_%2BzVvfOj=PzF3w@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman