linux-stable.git/arch/x86, branch linux-4.7.y

x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access

2016-10-16T15:50:38+00:00

commit 72b4f6a5e903b071f2a7c4eb1418cbe4eefdc344 upstream.

On x86_32, when an interrupt happens from kernel space, SS and SP aren't
pushed and the existing stack is used.  So pt_regs is effectively two
words shorter, and the previous stack pointer is normally the memory
after the shortened pt_regs, aka '®s->sp'.

But in the rare case where the interrupt hits right after the stack
pointer has been changed to point to an empty stack, like for example
when call_on_stack() is used, the address immediately after the
shortened pt_regs is no longer on the stack.  In that case, instead of
'®s->sp', the previous stack pointer should be retrieved from the
beginning of the current stack page.

kernel_stack_pointer() wants to do that, but it forgets to dereference
the pointer.  So instead of returning a pointer to the previous stack,
it returns a pointer to the beginning of the current stack.

Note that it's probably outside of kernel_stack_pointer()'s scope to be
switching stacks at all.  The x86_64 version of this function doesn't do
it, and it would be better for the caller to do it if necessary.  But
that's a patch for another day.  This just fixes the original intent.

Signed-off-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Fixes: 0788aa6a23cb ("x86: Prepare removal of previous_esp from i386 thread_info structure")
Link: http://lkml.kernel.org/r/472453d6e9f6a2d4ab16aaed4935f43117111566.1471535549.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/mm/pkeys: Do not skip PKRU register if debug registers are not used

2016-10-16T15:50:38+00:00

commit ba6d018e3d2f6a0fad58a668cadf66b2d1f80f59 upstream.

__show_regs() fails to dump the PKRU state when the debug registers are in
their default state because there is a return statement on the debug
register state.

Change the logic to report PKRU value even when debug registers are in
their default state.

Fixes:c0b17b5bd4b7 ("x86/mm/pkeys: Dump PKRU with other kernel registers")
Signed-off-by: Nicolas Iooss 
Acked-by: Dave Hansen 
Link: http://lkml.kernel.org/r/20160910183045.4618-1-nicolas.iooss_linux@m4x.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

arch/x86: Handle non enumerated CPU after physical hotplug

2016-10-16T15:50:38+00:00

commit 2a51fe083eba7f99cbda72f5ef90cdf2f4df882c upstream.

When a CPU is physically added to a system then the MADT table is not
updated.

If subsequently a kdump kernel is started on that physically added CPU then
the ACPI enumeration fails to provide the information for this CPU which is
now the boot CPU of the kdump kernel.

As a consequence, generic_processor_info() is not invoked for that CPU so
the number of enumerated processors is 0 and none of the initializations,
including the logical package id management, are performed.

We have code which relies on the correctness of the logical package map and
other information which is initialized via generic_processor_info().
Executing such code will result in undefined behaviour or kernel crashes.

This problem applies only to the kdump kernel because a normal kexec will
switch to the original boot CPU, which is enumerated in MADT, before
jumping into the kexec kernel.

The boot code already has a check for num_processors equal 0 in
prefill_possible_map(). We can use that check as an indicator that the
enumeration of the boot CPU did not happen and invoke generic_processor_info()
for it. That initializes the relevant data for the boot CPU and therefore
prevents subsequent failure.

[ tglx: Refined the code and rewrote the changelog ]

Signed-off-by: Prarit Bhargava 
Fixes: 1f12e32f4cd5 ("x86/topology: Create logical package id")
Cc: Peter Zijlstra 
Cc: Len Brown 
Cc: Borislav Petkov 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Juergen Gross 
Cc: dyoung@redhat.com
Cc: Eric Biederman 
Cc: kexec@lists.infradead.org
Link: http://lkml.kernel.org/r/1475514432-27682-1-git-send-email-prarit@redhat.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/apic: Get rid of apic_version[] array

2016-10-16T15:50:38+00:00

commit cff9ab2b291e64259d97add48fe073c081afe4e2 upstream.

The array has a size of MAX_LOCAL_APIC, which can be as large as 32k, so it
can consume up to 128k.

The array has been there forever and was never used for anything useful
other than a version mismatch check which was introduced in 2009.

There is no reason to store the version in an array. The kernel is not
prepared to handle different APIC versions anyway, so the real important
part is to detect a version mismatch and warn about it, which can be done
with a single variable as well.

[ tglx: Massaged changelog ]

Signed-off-by: Denys Vlasenko 
CC: Andy Lutomirski 
CC: Borislav Petkov 
CC: Brian Gerst 
CC: Mike Travis 
Link: http://lkml.kernel.org/r/20160913181232.30815-1-dvlasenk@redhat.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/pkeys: Make protection keys an "eager" feature

2016-10-16T15:50:38+00:00

commit d4b05923f579c234137317cdf9a5eb69ddab76d1 upstream.

Our XSAVE features are divided into two categories: those that
generate FPU exceptions, and those that do not.  MPX and pkeys do
not generate FPU exceptions and thus can not be used lazily.  We
disable them when lazy mode is forced on.

We have a pair of masks to collect these two sets of features, but
XFEATURE_MASK_PKRU was added to the wrong mask: XFEATURE_MASK_LAZY.
Fix it by moving the feature to XFEATURE_MASK_EAGER.

Note: this only causes problem if you boot with lazy FPU mode
(eagerfpu=off) which is *not* the default.  It also only affects
hardware which is not currently publicly available.  It looks like
eager mode is going away, but we still need this patch applied
to any kernel that has protection keys and lazy mode, which is 4.6
through 4.8 at this point, and 4.9 if the lazy removal isn't sent
to Linus for 4.9.

Fixes: c8df40098451 ("x86/fpu, x86/mm/pkeys: Add PKRU xsave fields and data structures")
Signed-off-by: Dave Hansen 
Cc: Dave Hansen 
Link: http://lkml.kernel.org/r/20161007162342.28A49813@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/irq: Prevent force migration of irqs which are not in the vector domain

2016-10-16T15:50:38+00:00

commit db91aa793ff984ac048e199ea1c54202543952fe upstream.

When a CPU is about to be offlined we call fixup_irqs() that resets IRQ
affinities related to the CPU in question. The same thing is also done when
the system is suspended to S-states like S3 (mem).

For each IRQ we try to complete any on-going move regardless whether the
IRQ is actually part of x86_vector_domain. For each IRQ descriptor we fetch
its chip_data, assume it is of type struct apic_chip_data and manipulate it
by clearing old_domain mask etc. For irq_chips that are not part of the
x86_vector_domain, like those created by various GPIO drivers, will find
their chip_data being changed unexpectly.

Below is an example where GPIO chip owned by pinctrl-sunrisepoint.c gets
corrupted after resume:

  # cat /sys/kernel/debug/gpio
  gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00:
   gpio-511 (                    |sysfs               ) in  hi

  # rtcwake -s10 -mmem
  <10 seconds passes>

  # cat /sys/kernel/debug/gpio
  gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00:
   gpio-511 (                    |sysfs               ) in  ?

Note '?' in the output. It means the struct gpio_chip ->get function is
NULL whereas before suspend it was there.

Fix this by first checking that the IRQ belongs to x86_vector_domain before
we try to use the chip_data as struct apic_chip_data.

Reported-and-tested-by: Sakari Ailus 
Signed-off-by: Mika Westerberg 
Link: http://lkml.kernel.org/r/20161003101708.34795-1-mika.westerberg@linux.intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation

2016-10-16T15:50:38+00:00

commit 917db484dc6a69969d317b3e57add4208a8d9d42 upstream.

In commit:

  ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 type")

Christoph references the original patch I wrote implementing pmem support.
The intent of the 'max_pfn' changes in that commit were to enable persistent
memory ranges to be covered by the struct page memmap by default.

However, that approach was abandoned when Christoph ported the patches [1], and
that functionality has since been replaced by devm_memremap_pages().

In the meantime, this max_pfn manipulation is confusing kdump [2] that
assumes that everything covered by the max_pfn is "System RAM".  This
results in kdump hanging or crashing.

 [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-March/000348.html
 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1351098

So fix it.

Reported-by: Zhang Yi 
Reported-by: Jeff Moyer 
Tested-by: Zhang Yi 
Signed-off-by: Dan Williams 
Reviewed-by: Jeff Moyer 
Cc: Andrew Morton 
Cc: Boaz Harrosh 
Cc: Christoph Hellwig 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Ross Zwisler 
Cc: Thomas Gleixner 
Cc: linux-nvdimm@lists.01.org
Fixes: ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 type")
Link: http://lkml.kernel.org/r/147448744538.34910.11287693517367139607.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

xen/x86: Update topology map for PV VCPUs

2016-10-16T15:50:37+00:00

commit a6a198bc60e6c980a56eca24d33dc7f29139f8ea upstream.

Early during boot topology_update_package_map() computes
logical_pkg_ids for all present processors.

Later, when processors are brought up, identify_cpu() updates
these values based on phys_pkg_id which is a function of
initial_apicid. On PV guests the latter may point to a
non-existing node, causing logical_pkg_ids to be set to -1.

Intel's RAPL uses logical_pkg_id (as topology_logical_package_id())
to index its arrays and therefore in this case will point to index
65535 (since logical_pkg_id is a u16). This could lead to either a
crash or may actually access random memory location.

As a workaround, we recompute topology during CPU bringup to reset
logical_pkg_id to a valid value.

(The reason for initial_apicid being bogus is because it is
initial_apicid of the processor from which the guest is launched.
This value is CPUID(1).EBX[31:24])

Signed-off-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

KVM: nVMX: postpone VMCS changes on MSR_IA32_APICBASE write

2016-10-07T13:21:26+00:00

commit dccbfcf52cebb8963246eba5b177b77f26b34da0 upstream.

If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the
write with vmcs02 as the current VMCS.
This will incorrectly apply modifications intended for vmcs01 to vmcs02
and L2 can use it to gain access to L0's x2APIC registers by disabling
virtualized x2APIC while using msr bitmap that assumes enabled.

Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the
current VMCS.  An alternative solution would temporarily make vmcs01 the
current VMCS, but it requires more care.

Fixes: 8d14695f9542 ("x86, apicv: add virtual x2apic support")
Reported-by: Jim Mattson 
Reviewed-by: Wanpeng Li 
Signed-off-by: Radim Krčmář 
Signed-off-by: Greg Kroah-Hartman

x86/boot: Initialize FPU and X86_FEATURE_ALWAYS even if we don't have CPUID

2016-10-07T13:21:16+00:00

commit 05fb3c199bb09f5b85de56cc3ede194ac95c5e1f upstream.

Otherwise arch_task_struct_size == 0 and we die.  While we're at it,
set X86_FEATURE_ALWAYS, too.

Reported-by: David Saggiorato 
Tested-by: David Saggiorato 
Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: aaeb5c01c5b ("x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and use it on x86")
Link: http://lkml.kernel.org/r/8de723afbf0811071185039f9088733188b606c9.1475103911.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman