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

x86: fix boot on uniprocessor systems

2014-04-03T19:01:05+00:00

commit 825600c0f20e595daaa7a6dd8970f84fa2a2ee57 upstream.

On x86 uniprocessor systems topology_physical_package_id() returns -1
which causes rapl_cpu_prepare() to leave rapl_pmu variable uninitialized
which leads to GPF in rapl_pmu_init().

See arch/x86/kernel/cpu/perf_event_intel_rapl.c.

It turns out that physical_package_id and core_id can actually be
retreived for uniprocessor systems too.  Enabling them also fixes
rapl_pmu code.

Signed-off-by: Artem Fetishev 
Cc: Stephane Eranian 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

KVM: VMX: fix use after free of vmx->loaded_vmcs

2014-03-31T16:58:14+00:00

commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.

After free_loaded_vmcs executes, the "loaded_vmcs" structure
is kfreed, and now vmx->loaded_vmcs points to a kfreed area.
Subsequent free_loaded_vmcs then attempts to manipulate
vmx->loaded_vmcs.

Switch the order to avoid the problem.

https://bugzilla.redhat.com/show_bug.cgi?id=1047892

Reviewed-by: Jan Kiszka 
Signed-off-by: Marcelo Tosatti 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: handle invalid root_hpa everywhere

2014-03-31T16:58:14+00:00

commit 37f6a4e237303549c8676dfe1fd1991ceab512eb upstream.

Rom Freiman  notes other code paths vulnerable to
bug fixed by 989c6b34f6a9480e397b.

Signed-off-by: Marcelo Tosatti 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

KVM: MMU: handle invalid root_hpa at __direct_map

2014-03-31T16:58:14+00:00

commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.

It is possible for __direct_map to be called on invalid root_hpa
(-1), two examples:

1) try_async_pf -> can_do_async_pf
    -> vmx_interrupt_allowed -> nested_vmx_vmexit
2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit

Then to load_vmcs12_host_state and kvm_mmu_reset_context.

Check for this possibility, let fault exception be regenerated.

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916

Signed-off-by: Marcelo Tosatti 
Signed-off-by: Paolo Bonzini 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

ARM: highbank: avoid L2 cache smc calls when PL310 is not present

2014-03-31T16:58:13+00:00

commit a56a5cf1f2ec895599eace0ac6eba1e4a489e4bf upstream.

While Midway firmware handles L2 smc calls as nops, the custom smc calls
present a problem when running virtualized Midway guest. They aren't
needed so just avoid calling them.

In the process, cleanup the L2X0 ifdefs and use IS_ENABLED instead.

Signed-off-by: Rob Herring 
Signed-off-by: Ian Campbell 
Signed-off-by: Greg Kroah-Hartman

ARM: move outer_cache declaration out of ifdef

2014-03-31T16:58:13+00:00

commit 0b53c11d533a8f6688d73fad0baf67dd08ec1b90 upstream.

Move the outer_cache declaration of the CONFIG_OUTER_CACHE ifdef so that
outer_cache can be used inside IS_ENABLED condition.

Signed-off-by: Rob Herring 
Cc: Russell King 
Signed-off-by: Ian Campbell 
Signed-off-by: Greg Kroah-Hartman

x86: bpf_jit: support negative offsets

2014-03-31T16:58:13+00:00

commit fdfaf64e75397567257e1051931f9a3377360665 upstream.

Commit a998d4342337 claimed to introduce negative offset support to x86 jit,
but it couldn't be working, since at the time of the execution
of LD+ABS or LD+IND instructions via call into
bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func)
had junk value instead of access size in bytes (1 or 2 or 4).

Store size into %edx instead of %ecx (what original commit intended to do)

Fixes: a998d4342337 ("bpf jit: Let the x86 jit handle negative offsets")
Signed-off-by: Alexei Starovoitov 
Cc: Jan Seiffert 
Cc: Eric Dumazet 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ARM: ignore memory below PHYS_OFFSET

2014-03-24T04:38:21+00:00

commit 571b14375019c3a66ef70d4d4a7083f4238aca30 upstream.

If the kernel is loaded higher in physical memory than normal, and we
calculate PHYS_OFFSET higher than the start of RAM, this leads to
boot problems as we attempt to map part of this RAM into userspace.
Rather than struggle with this, just truncate the mapping.

Signed-off-by: Russell King 
Cc: Wang Nan 
Signed-off-by: Greg Kroah-Hartman

ARM: 7864/1: Handle 64-bit memory in case of 32-bit phys_addr_t

2014-03-24T04:38:21+00:00

commit 6d7d5da7d75c6df676c8b72d32b02ff024438f0c upstream.

Use CONFIG_ARCH_PHYS_ADDR_T_64BIT to determine
if ignoring or truncating of memory banks is
neccessary. This may be needed in the case of
64-bit memory bank addresses but when phys_addr_t
is kept 32-bit.

Signed-off-by: Magnus Damm 
Signed-off-by: Russell King 
Cc: Wang Nan 
Signed-off-by: Greg Kroah-Hartman

MIPS: include linux/types.h

2014-03-24T04:38:20+00:00

commit 87c99203fea897fbdd84b681ad9fced2517dcf98 upstream.

The file uses u16 type but doesn't include its definition explicitly

I was getting this error when including this header in my driver:

  arch/mips/include/asm/mipsregs.h:644:33: error: unknown type name ‘u16’

Signed-off-by: Qais Yousef 
Reviewed-by: Steven J. Hill 
Acked-by: David Daney 
Signed-off-by: John Crispin 
Patchwork: http://patchwork.linux-mips.org/patch/6212/
Signed-off-by: Greg Kroah-Hartman