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

clockevent: Prevent dead lock on clockevents_lock

2010-05-26T21:27:07+00:00

This is a merge of two mainline commits, intended
for stable@kernel.org submission for 2.6.27 kernel.

commit f833bab87fca5c3ce13778421b1365845843b976
and

commit 918aae42aa9b611a3663b16ae849fdedc67c2292
Changelog of both:

    Currently clockevents_notify() is called with interrupts enabled at
    some places and interrupts disabled at some other places.

    This results in a deadlock in this scenario.

    cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
    cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
    cpu C doing set_mtrr() which will try to rendezvous of all the cpus.

    This will result in C and A come to the rendezvous point and waiting
    for B. B is stuck forever waiting for the spinlock and thus not
    reaching the rendezvous point.

    Fix the clockevents code so that clockevents_lock is taken with
    interrupts disabled and thus avoid the above deadlock.

    Also call lapic_timer_propagate_broadcast() on the destination cpu so
    that we avoid calling smp_call_function() in the clockevents notifier
    chain.

    This issue left us wondering if we need to change the MTRR rendezvous
    logic to use stop machine logic (instead of smp_call_function) or add
    a check in spinlock debug code to see if there are other spinlocks
    which gets taken under both interrupts enabled/disabled conditions.

    Signed-off-by: Suresh Siddha 
    Cc: "Brown Len" 
    Cc: stable@kernel.org
    LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com>
    Signed-off-by: Thomas Gleixner 

    I got following warning on ia64 box:
      In function 'acpi_processor_power_verify':
      642: warning: passing argument 2 of 'smp_call_function_single' from
      incompatible pointer type

    This smp_call_function_single() was introduced by a commit
    f833bab87fca5c3ce13778421b1365845843b976:

    The problem is that the lapic_timer_propagate_broadcast() has 2 versions:
    One is real code that modified in the above commit, and the other is NOP
    code that used when !ARCH_APICTIMER_STOPS_ON_C3:

      static void lapic_timer_propagate_broadcast(struct acpi_processor *pr) { }

    So I got warning because of !ARCH_APICTIMER_STOPS_ON_C3.

    We really want to do nothing here on !ARCH_APICTIMER_STOPS_ON_C3, so
    modify lapic_timer_propagate_broadcast() of real version to use
    smp_call_function_single() in it.

    Signed-off-by: Hidetoshi Seto 
    Acked-by: Suresh Siddha 
    Signed-off-by: Len Brown 

Signed-off-by: Thomas Renninger 
Signed-off-by: Greg Kroah-Hartman

x86, ia32_aout: do not kill argument mapping

2010-04-01T22:52:26+00:00

commit 318f6b228ba88a394ef560efc1bfe028ad5ae6b6 upstream.

Do not set current->mm->mmap to NULL in 32-bit emulation on 64-bit
load_aout_binary after flush_old_exec as it would destroy already
set brpm mapping with arguments.

Introduced by b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
mm: variable length argument support
where the argument mapping in bprm was added.

[ hpa: this is a regression from 2.6.22... time to kill a.out? ]

Signed-off-by: Jiri Slaby 
LKML-Reference: <1265831716-7668-1-git-send-email-jslaby@suse.cz>
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Ollie Wild 
Cc: x86@kernel.org
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: check for cr3 validity in ioctl_set_sregs

2010-04-01T22:52:25+00:00

commit 59839dfff5eabca01cc4e20b45797a60a80af8cb upstream.

Matt T. Yourst notes that kvm_arch_vcpu_ioctl_set_sregs lacks validity
checking for the new cr3 value:

"Userspace callers of KVM_SET_SREGS can pass a bogus value of cr3 to
the kernel. This will trigger a NULL pointer access in gfn_to_rmap()
when userspace next tries to call KVM_RUN on the affected VCPU and kvm
attempts to activate the new non-existent page table root.

This happens since kvm only validates that cr3 points to a valid guest
physical memory page when code *inside* the guest sets cr3. However, kvm
currently trusts the userspace caller (e.g. QEMU) on the host machine to
always supply a valid page table root, rather than properly validating
it along with the rest of the reloaded guest state."

http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2687641&group_id=180599

Check for a valid cr3 address in kvm_arch_vcpu_ioctl_set_sregs, triple
fault in case of failure.

Signed-off-by: Marcelo Tosatti 
Signed-off-by: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman

KVM: VMX: Check cpl before emulating debug register access

2010-04-01T22:52:24+00:00

commit 0a79b009525b160081d75cef5dbf45817956acf2 upstream.

Debug registers may only be accessed from cpl 0.  Unfortunately, vmx will
code to emulate the instruction even though it was issued from guest
userspace, possibly leading to an unexpected trap later.

Signed-off-by: Avi Kivity 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Greg Kroah-Hartman

KVM: x86 emulator: limit instructions to 15 bytes

2010-04-01T22:52:23+00:00

commit eb3c79e64a70fb8f7473e30fa07e89c1ecc2c9bb upstream

[ : backport to 2.6.27 ]

While we are never normally passed an instruction that exceeds 15 bytes,
smp games can cause us to attempt to interpret one, which will cause
large latencies in non-preempt hosts.

Signed-off-by: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman

KVM: S390: fix potential array overrun in intercept handling

2010-01-28T23:20:41+00:00

commit 062d5e9b0d714f449b261bb522eadaaf6f00f438 upstream.

kvm_handle_sie_intercept uses a jump table to get the intercept handler
for a SIE intercept. Static code analysis revealed a potential problem:
the intercept_funcs jump table was defined to contain (0x48 >> 2) entries,
but we only checked for code > 0x48 which would cause an off-by-one
array overflow if code == 0x48.

Use the compiler and ARRAY_SIZE to automatically set the limits.

Signed-off-by: Christian Borntraeger 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Greg Kroah-Hartman

powerpc: Handle VSX alignment faults correctly in little-endian mode

2010-01-18T18:34:03+00:00

commit bb7f20b1c639606def3b91f4e4aca6daeee5d80a upstream.

This patch fixes the handling of VSX alignment faults in little-endian
mode (the current code assumes the processor is in big-endian mode).

The patch also makes the handlers clear the top 8 bytes of the register
when handling an 8 byte VSX load.

This is based on 2.6.32.

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

powerpc: Disable VSX or current process in giveup_fpu/altivec

2010-01-18T18:34:01+00:00

commit 7e875e9dc8af70d126fa632446e967327ac3fdda upstream.

When we call giveup_fpu, we need to need to turn off VSX for the
current process.  If we don't, on return to userspace it may execute a
VSX instruction before the next FP instruction, and not have its
register state refreshed correctly from the thread_struct.  Ditto for
altivec.

This caused a bug where an unaligned lfs or stfs results in
fix_alignment calling giveup_fpu so it can use the FPRs (in order to
do a single <-> double conversion), and then returning to userspace
with FP off but VSX on.  Then if a VSX instruction is executed, before
another FP instruction, it will proceed without another exception and
hence have the incorrect register state for VSX registers 0-31.

   lfs unaligned   <- alignment exception turns FP off but leaves VSX on

   VSX instruction <- no exception since VSX on, hence we get the
                      wrong VSX register values for VSX registers 0-31,
                      which overlap the FPRs.

Signed-off-by: Michael Neuling 
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

Revert: KVM: MMU: do not free active mmu pages in free_mmu_pages()

2010-01-06T23:17:21+00:00

This reverts the commit d2127c8300fb1ec54af56faee17170e7a525326d, which was
the commit f00be0cae4e6ad0a8c7be381c6d9be3586800b3e upstream.

This was done based on comments saying it was causing problems.

Cc: Gleb Natapov 
Cc: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman

x86/ptrace: make genregs[32]_get/set more robust

2010-01-06T23:17:16+00:00

commit 04a1e62c2cec820501f93526ad1e46073b802dc4 upstream.

The loop condition is fragile: we compare an unsigned value to zero, and
then decrement it by something larger than one in the loop.  All the
callers should be passing in appropriately aligned buffer lengths, but
it's better to just not rely on it, and have some appropriate defensive
loop limits.

Acked-by: Roland McGrath 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman