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

x86/mm/hotplug: Modify PGD entry when removing memory

2015-11-18T12:42:46+00:00

commit 9661d5bcd058fe15b4138a00d96bd36516134543 upstream.

When hot-adding/removing memory, sync_global_pgds() is called
for synchronizing PGD to PGD entries of all processes MM.  But
when hot-removing memory, sync_global_pgds() does not work
correctly.

At first, sync_global_pgds() checks whether target PGD is none
or not.  And if PGD is none, the PGD is skipped.  But when
hot-removing memory, PGD may be none since PGD may be cleared by
free_pud_table().  So when sync_global_pgds() is called after
hot-removing memory, sync_global_pgds() should not skip PGD even
if the PGD is none.  And sync_global_pgds() must clear PGD
entries of all processes MM.

Currently sync_global_pgds() does not clear PGD entries of all
processes MM when hot-removing memory.  So when hot adding
memory which is same memory range as removed memory after
hot-removing memory, following call traces are shown:

 kernel BUG at arch/x86/mm/init_64.c:206!
 ...
 [] kernel_physical_mapping_init+0x1b2/0x1d2
 [] init_memory_mapping+0x1d4/0x380
 [] arch_add_memory+0x3d/0xd0
 [] add_memory+0xb9/0x1b0
 [] acpi_memory_device_add+0x1af/0x28e
 [] acpi_bus_device_attach+0x8c/0xf0
 [] acpi_ns_walk_namespace+0xc8/0x17f
 [] ? acpi_bus_type_and_status+0xb7/0xb7
 [] ? acpi_bus_type_and_status+0xb7/0xb7
 [] acpi_walk_namespace+0x95/0xc5
 [] acpi_bus_scan+0x9a/0xc2
 [] acpi_scan_bus_device_check+0x8b/0x12e
 [] acpi_scan_device_check+0x13/0x15
 [] acpi_os_execute_deferred+0x25/0x32
 [] process_one_work+0x17b/0x460
 [] worker_thread+0x11b/0x400
 [] ? rescuer_thread+0x400/0x400
 [] kthread+0xcf/0xe0
 [] ? kthread_create_on_node+0x140/0x140
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x140/0x140

This patch clears PGD entries of all processes MM when
sync_global_pgds() is called after hot-removing memory

Signed-off-by: Yasuaki Ishimatsu 
Acked-by: Toshi Kani 
Signed-off-by: Andrew Morton 
Cc: Tang Chen 
Cc: Gu Zheng 
Cc: Zhang Yanfei 
Cc: Linus Torvalds 
Signed-off-by: Ingo Molnar 
Cc: Vlastimil Babka 
Signed-off-by: Jiri Slaby

x86/mm/hotplug: Pass sync_global_pgds() a correct argument in remove_pagetable()

2015-11-18T12:42:37+00:00

commit 5255e0a79fcc0ff47b387af92bd9ef5729b1b859 upstream.

When hot-adding memory after hot-removing memory, following call
traces are shown:

  kernel BUG at arch/x86/mm/init_64.c:206!
  ...
 [] kernel_physical_mapping_init+0x1b2/0x1d2
 [] init_memory_mapping+0x1d4/0x380
 [] arch_add_memory+0x3d/0xd0
 [] add_memory+0xb9/0x1b0
 [] acpi_memory_device_add+0x1af/0x28e
 [] acpi_bus_device_attach+0x8c/0xf0
 [] acpi_ns_walk_namespace+0xc8/0x17f
 [] ? acpi_bus_type_and_status+0xb7/0xb7
 [] ? acpi_bus_type_and_status+0xb7/0xb7
 [] acpi_walk_namespace+0x95/0xc5
 [] acpi_bus_scan+0x9a/0xc2
 [] acpi_scan_bus_device_check+0x8b/0x12e
 [] acpi_scan_device_check+0x13/0x15
 [] acpi_os_execute_deferred+0x25/0x32
 [] process_one_work+0x17b/0x460
 [] worker_thread+0x11b/0x400
 [] ? rescuer_thread+0x400/0x400
 [] kthread+0xcf/0xe0
 [] ? kthread_create_on_node+0x140/0x140
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x140/0x140

The patch-set fixes the issue.

This patch (of 2):

remove_pagetable() gets start argument and passes the argument
to sync_global_pgds().  In this case, the argument must not be
modified.  If the argument is modified and passed to
sync_global_pgds(), sync_global_pgds() does not correctly
synchronize PGD to PGD entries of all processes MM since
synchronized range of memory [start, end] is wrong.

Unfortunately the start argument is modified in
remove_pagetable().  So this patch fixes the issue.

Signed-off-by: Yasuaki Ishimatsu 
Acked-by: Toshi Kani 
Signed-off-by: Andrew Morton 
Cc: Tang Chen 
Cc: Gu Zheng 
Cc: Zhang Yanfei 
Cc: Linus Torvalds 
Signed-off-by: Ingo Molnar 
Cc: Vlastimil Babka 
Signed-off-by: Jiri Slaby

KVM: x86: Use new is_noncanonical_address in _linearize

2015-11-18T11:43:22+00:00

commit 4be4de7ef9fd3a4d77320d4713970299ffecd286 upstream.

Replace the current canonical address check with the new function which is
identical.

Signed-off-by: Nadav Amit 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KVM: x86: Fix far-jump to non-canonical check

2015-11-18T10:28:01+00:00

commit 7e46dddd6f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream.

Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far
jumps") introduced a bug that caused the fix to be incomplete.  Due to
incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit
segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may
not trigger #GP.  As we know, this imposes a security problem.

In addition, the condition for two warnings was incorrect.

Fixes: d1442d85cc30ea75f7d399474ca738e0bc96f715
Reported-by: Dan Carpenter 
Signed-off-by: Nadav Amit 
[Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo]
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KVM: svm: unconditionally intercept #DB

2015-11-18T10:08:02+00:00

commit cbdb967af3d54993f5814f1cee0ed311a055377d upstream.

This is needed to avoid the possibility that the guest triggers
an infinite stream of #DB exceptions (CVE-2015-8104).

VMX is not affected: because it does not save DR6 in the VMCS,
it already intercepts #DB unconditionally.

Reported-by: Jan Beulich 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KVM: x86: work around infinite loop in microcode when #AC is delivered

2015-11-18T10:08:01+00:00

commit 54a20552e1eae07aa240fa370a0293e006b5faed upstream.

It was found that a guest can DoS a host by triggering an infinite
stream of "alignment check" (#AC) exceptions.  This causes the
microcode to enter an infinite loop where the core never receives
another interrupt.  The host kernel panics pretty quickly due to the
effects (CVE-2015-5307).

Signed-off-by: Eric Northup 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

KVM: x86: Defining missing x86 vectors

2015-11-18T10:08:00+00:00

commit c9cdd085bb75226879fd468b88e2e7eb467325b7 upstream.

Defining XE, XM and VE vector numbers.

Signed-off-by: Nadav Amit 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Jiri Slaby

ARM: orion: Fix DSA platform device after mvmdio conversion

2015-11-14T17:58:27+00:00

commit d836ace65ee98d7079bc3c5afdbcc0e27dca20a3 upstream.

DSA expects the host_dev pointer to be the device structure associated
with the MDIO bus controller driver. First commit breaking that was
c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO
driver"), and then, it got completely under the radar for a while.

Reported-by: Frans van de Wiel 
Fixes: c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver")
CC: stable@vger.kernel.org
Signed-off-by: Florian Fainelli 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Jiri Slaby

powerpc/pseries: Fix dedicated processor partition detection

2015-11-14T16:48:50+00:00

commit 733187e29576041ceccf3b82092ca900fc929170 upstream.

commit f13c13a00512 (powerpc: Stop using non-architected shared_proc
field in lppaca) fixed a potential issue with shared/dedicated
partition detection. The old method of detection relied on an
unarchitected field (shared_proc), and this patch switched
to using something architected (a non zero yield_count).

Unfortunately the assertion in the Linux header that yield_count
is only non zero on shared processor partitions is not true. It
turns out dedicated processor partitions can increment yield_count
and as such we falsely detect dedicated partitions as shared.

Fix the comment, and switch back to using the old method.

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Jiri Slaby

Revert "ARM64: unwind: Fix PC calculation"

2015-11-12T13:08:58+00:00

commit 9702970c7bd3e2d6fecb642a190269131d4ac16c upstream.

This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63.

With this patch applied, we were the only architecture making this sort
of adjustment to the PC calculation in the unwinder. This causes
problems for ftrace, where the PC values are matched against the
contents of the stack frames in the callchain and fail to match any
records after the address adjustment.

Whilst there has been some effort to change ftrace to workaround this,
those patches are not yet ready for mainline and, since we're the odd
architecture in this regard, let's just step in line with other
architectures (like arch/arm/) for now.

Signed-off-by: Will Deacon 
Signed-off-by: Jiri Slaby