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

x86: Fix mmap random address range

2012-01-18T15:31:58+00:00

commit 9af0c7a6fa860698d080481f24a342ba74b68982 upstream.

On x86_32 casting the unsigned int result of get_random_int() to
long may result in a negative value.  On x86_32 the range of
mmap_rnd() therefore was -255 to 255.  The 32bit mode on x86_64
used 0 to 255 as intended.

The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c")
in January 2008.

Signed-off-by: Ludwig Nussel 
Cc: Linus Torvalds 
Cc: harvey.harrison@gmail.com
Cc: "H. Peter Anvin" 
Cc: Harvey Harrison 
Signed-off-by: Andrew Morton 
Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/PCI: build amd_bus.o only when CONFIG_AMD_NB=y

2012-01-18T15:31:56+00:00

commit 5cf9a4e69c1ff0ccdd1d2b7404f95c0531355274 upstream.

We only need amd_bus.o for AMD systems with PCI.  arch/x86/pci/Makefile
already depends on CONFIG_PCI=y, so this patch just adds the dependency
on CONFIG_AMD_NB.

Cc: Yinghai Lu 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

x86/PCI: amd: factor out MMCONFIG discovery

2012-01-18T15:31:56+00:00

commit 24d25dbfa63c376323096660bfa9ad45a08870ce upstream.

This factors out the AMD native MMCONFIG discovery so we can use it
outside amd_bus.c.

amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the
PCI resources.  We may also need the MMCONFIG information to work
around BIOS defects in the ACPI MCFG table.

Cc: Borislav Petkov 
Cc: Yinghai Lu 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

x86/PCI: Ignore CPU non-addressable _CRS reserved memory resources

2012-01-18T15:31:56+00:00

commit ae5cd86455381282ece162966183d3f208c6fad7 upstream.

This assures that a _CRS reserved host bridge window or window region is
not used if it is not addressable by the CPU.  The new code either trims
the window to exclude the non-addressable portion or totally ignores the
window if the entire window is non-addressable.

The current code has been shown to be problematic with 32-bit non-PAE
kernels on systems where _CRS reserves resources above 4GB.

Signed-off-by: Gary Hade 
Reviewed-by: Bjorn Helgaas 
Cc: Thomas Renninger 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: Prevent starting PIT timers in the absence of irqchip support

2012-01-18T15:31:53+00:00

(cherry picked from commit 0924ab2cfa98b1ece26c033d696651fd62896c69)

User space may create the PIT and forgets about setting up the irqchips.
In that case, firing PIT IRQs will crash the host:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000128
IP: [] kvm_set_irq+0x30/0x170 [kvm]
...
Call Trace:
 [] pit_do_work+0x51/0xd0 [kvm]
 [] process_one_work+0x111/0x4d0
 [] worker_thread+0x152/0x340
 [] kthread+0x7e/0x90
 [] kernel_thread_helper+0x4/0x10

Prevent this by checking the irqchip mode before starting a timer. We
can't deny creating the PIT if the irqchips aren't set up yet as
current user land expects this order to work.

Signed-off-by: Jan Kiszka 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Greg Kroah-Hartman

KVM guest: prevent tracing recursion with kvmclock

2012-01-18T15:31:53+00:00

(cherry picked from commit 95ef1e52922cf75b1ea2eae54ef886f2cc47eecb)

Prevent tracing of preempt_disable() in get_cpu_var() in
kvm_clock_read(). When CONFIG_DEBUG_PREEMPT is enabled,
preempt_disable/enable() are traced and this causes the function_graph
tracer to go into an infinite recursion. By open coding the
preempt_disable() around the get_cpu_var(), we can use the notrace
version which prevents preempt_disable/enable() from being traced and
prevents the recursion.

Based on a similar patch for Xen from Jeremy Fitzhardinge.

Tested-by: Gleb Natapov 
Acked-by: Steven Rostedt 
Signed-off-by: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix unpaired probe_hcall_entry and probe_hcall_exit

2012-01-12T19:33:14+00:00

commit e4f387d8db3ba3c2dae4d8bdfe7bb5f4fe1bcb0d upstream.

Unpaired calling of probe_hcall_entry and probe_hcall_exit might happen
as following, which could cause incorrect preempt count.

__trace_hcall_entry => trace_hcall_entry -> probe_hcall_entry =>
get_cpu_var => preempt_disable

__trace_hcall_exit => trace_hcall_exit -> probe_hcall_exit =>
put_cpu_var => preempt_enable

where:
A => B and A -> B means A calls B, but
=> means A will call B through function name, and B will definitely be
called.
-> means A will call B through function pointer, so B might not be
called if the function pointer is not set.

So error happens when only one of probe_hcall_entry and probe_hcall_exit
get called during a hcall.

This patch tries to move the preempt count operations from
probe_hcall_entry and probe_hcall_exit to its callers.

Reported-by: Paul E. McKenney 
Signed-off-by: Li Zhong 
Tested-by: Paul E. McKenney 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/time: Handle wrapping of decrementer

2012-01-12T19:33:13+00:00

commit 37fb9a0231ee43d42d069863bdfd567fca2b61af upstream.

When re-enabling interrupts we have code to handle edge sensitive
decrementers by resetting the decrementer to 1 whenever it is negative.
If interrupts were disabled long enough that the decrementer wrapped to
positive we do nothing. This means interrupts can be delayed for a long
time until it finally goes negative again.

While we hope interrupts are never be disabled long enough for the
decrementer to go positive, we have a very good test team that can
drive any kernel into the ground. The softlockup data we get back
from these fails could be seconds in the future, completely missing
the cause of the lockup.

We already keep track of the timebase of the next event so use that
to work out if we should trigger a decrementer exception.

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

net: bpf_jit: fix an off-one bug in x86_64 cond jump target

2012-01-06T22:17:26+00:00

[ Upstream commit a03ffcf873fe0f2565386ca8ef832144c42e67fa ]

x86 jump instruction size is 2 or 5 bytes (near/long jump), not 2 or 6
bytes.

In case a conditional jump is followed by a long jump, conditional jump
target is one byte past the start of target instruction.

Signed-off-by: Markus Kötter 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Fix handling of orig_i0 wrt. debugging when restarting syscalls.

2012-01-06T22:17:25+00:00

[ A combination of upstream commits 1d299bc7732c34d85bd43ac1a8745f5a2fed2078 and
  e88d2468718b0789b4c33da2f7e1cef2a1eee279 ]

Although we provide a proper way for a debugger to control whether
syscall restart occurs, we run into problems because orig_i0 is not
saved and restored properly.

Luckily we can solve this problem without having to make debuggers
aware of the issue.  Across system calls, several registers are
considered volatile and can be safely clobbered.

Therefore we use the pt_regs save area of one of those registers, %g6,
as a place to save and restore orig_i0.

Debuggers transparently will do the right thing because they save and
restore this register already.

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