linux-stable.git/arch/x86/kernel, branch linux-3.3.y

MCE: Fix vm86 handling for 32bit mce handler

2012-06-01T07:15:55+00:00

commit a129a7c84582629741e5fa6f40026efcd7a65bd4 upstream.

When running on 32bit the mce handler could misinterpret
vm86 mode as ring 0. This can affect whether it does recovery
or not; it was possible to panic when recovery was actually
possible.

Fix this by always forcing vm86 to look like ring 3.

Signed-off-by: Andi Kleen 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman

x86/mce: Fix check for processor context when machine check was taken.

2012-06-01T07:15:53+00:00

commit 875e26648cf9b6db9d8dc07b7959d7c61fb3f49c upstream.

Linus pointed out that there was no value is checking whether m->ip
was zero - because zero is a legimate value.  If we have a reliable
(or faked in the VM86 case) "m->cs" we can use it to tell whether we
were in user mode or kernelwhen the machine check hit.

Reported-by: Linus Torvalds 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman

perf/x86: Update event scheduling constraints for AMD family 15h models

2012-06-01T07:15:43+00:00

commit 5bcdf5e4fee3c45e1281c25e4941f2163cb28c65 upstream.

This update is for newer family 15h cpu models from 0x02 to 0x1f.

Signed-off-by: Robert Richter 
Acked-by: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/1337337642-1621-1-git-send-email-robert.richter@amd.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit

2012-05-12T16:32:05+00:00

commit d5e28005a1d2e67833852f4c9ea8ec206ea3ff85 upstream.

With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE
or PMD_SIZE for atom_size.  PMD_SIZE is used when CPU supports PSE so
that percpu areas are aligned to PMD mappings and possibly allow using
PMD mappings in vmalloc areas in the future.  Using larger atom_size
doesn't waste actual memory; however, it does require larger vmalloc
space allocation later on for !first chunks.

With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem
but x86_32 at this point is anything but reasonable in terms of
address space and using larger atom_size reportedly leads to frequent
percpu allocation failures on certain setups.

As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space
is aplenty and most x86_64 configurations support PSE, fix the issue
by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32.

v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and
    x86_32 PAGE_SIZE as suggested by hpa.

Signed-off-by: Tejun Heo 
Reported-by: Yanmin Zhang 
Reported-by: ShuoX Liu 
Acked-by: H. Peter Anvin 
LKML-Reference: <4F97BA98.6010001@intel.com>
Signed-off-by: Greg Kroah-Hartman

i387: ptrace breaks the lazy-fpu-restore logic

2012-05-07T15:53:22+00:00

commit 089f9fba56faf33cc6dd2a6442b7ac92c58b8209 upstream.

Starting from 7e16838d "i387: support lazy restore of FPU state"
we assume that fpu_owner_task doesn't need restore_fpu_checking()
on the context switch, its FPU state should match what we already
have in the FPU on this CPU.

However, debugger can change the tracee's FPU state, in this case
we should reset fpu.last_cpu to ensure fpu_lazy_restore() can't
return true.

Change init_fpu() to do this, it is called by user_regset->set()
methods.

Reported-by: Jan Kratochvil 
Suggested-by: Linus Torvalds 
Signed-off-by: Oleg Nesterov 
Link: http://lkml.kernel.org/r/20120416204815.GB24884@redhat.com
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86/platform: Remove incorrect error message in x86_default_fixup_cpu_id()

2012-05-07T15:53:19+00:00

commit 68894632afb2729a1d8785c877840953894c7283 upstream.

It's only called from amd.c:srat_detect_node(). The introduced
condition for calling the fixup code is true for all AMD
multi-node processors, e.g. Magny-Cours and Interlagos. There we
have 2 NUMA nodes on one socket. Thus there are cores having
different numa-node-id but with equal phys_proc_id.

There is no point to print error messages in such a situation.

The confusing/misleading error message was introduced with
commit 64be4c1c2428e148de6081af235e2418e6a66dda ("x86: Add
x86_init platform override to fix up NUMA core numbering").

Remove the default fixup function (especially the error message)
and replace it by a NULL pointer check, move the
Numascale-specific condition for calling the fixup into the
fixup-function itself and slightly adapt the comment.

Signed-off-by: Andreas Herrmann 
Acked-by: Borislav Petkov 
Cc: 
Cc: 
Cc: 
Link: http://lkml.kernel.org/r/20120402160648.GR27684@alberich.amd.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, apic: APIC code touches invalid MSR on P5 class machines

2012-05-07T15:53:19+00:00

commit cbf2829b61c136edcba302a5e1b6b40e97d32c00 upstream.

Current APIC code assumes MSR_IA32_APICBASE is present for all systems.
Pentium Classic P5 and friends didn't have this MSR. MSR_IA32_APICBASE
was introduced as an architectural MSR by Intel @ P6.

Code paths that can touch this MSR invalidly are when vendor == Intel &&
cpu-family == 5 and APIC bit is set in CPUID - or when you simply pass
lapic on the kernel command line, on a P5.

The below patch stops Linux incorrectly interfering with the
MSR_IA32_APICBASE for P5 class machines. Other code paths exist that
touch the MSR - however those paths are not currently reachable for a
conformant P5.

Signed-off-by: Bryan O'Donoghue 
Link: http://lkml.kernel.org/r/4F8EEDD3.1080404@linux.intel.com
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, microcode: Ensure that module is only loaded on supported AMD CPUs

2012-05-07T15:53:19+00:00

commit 283c1f2558ef4a4411fe908364b15b73b6ab44cf upstream.

Exit early when there's no support for a particular CPU family. Also,
fixup the "no support for this CPU vendor" to be issued only when the
driver is attempted to be loaded on an unsupported vendor.

Cc: Tigran Aivazian 
Signed-off-by: Andreas Herrmann 
Acked-by: Greg Kroah-Hartman 
Link: http://lkml.kernel.org/r/20120411163849.GE4794@alberich.amd.com
[Boris: add a commit msg because Andreas is lazy]
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

x86, microcode: Fix sysfs warning during module unload on unsupported CPUs

2012-05-07T15:53:19+00:00

commit a956bd6f8583326b18348ab1452b4686778f785d upstream.

Loading the microcode driver on an unsupported CPU and subsequently
unloading the driver causes

 WARNING: at fs/sysfs/group.c:138 mc_device_remove+0x5f/0x70 [microcode]()
 Hardware name: 01972NG
 sysfs group ffffffffa00013d0 not found for kobject 'cpu0'
 Modules linked in: snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel btusb snd_hda_codec bluetooth thinkpad_acpi rfkill microcode(-) [last unloaded: cfg80211]
 Pid: 4560, comm: modprobe Not tainted 3.4.0-rc2-00002-g258f742 #5
 Call Trace:
  [] ? warn_slowpath_common+0x7b/0xc0
  [] ? warn_slowpath_fmt+0x45/0x50
  [] ? sysfs_remove_group+0x34/0x120
  [] ? mc_device_remove+0x5f/0x70 [microcode]
  [] ? subsys_interface_unregister+0x69/0xa0
  [] ? mutex_lock+0x16/0x40
  [] ? microcode_exit+0x50/0x92 [microcode]
  [] ? sys_delete_module+0x16d/0x260
  [] ? wait_iff_congested+0x45/0x110
  [] ? page_fault+0x1f/0x30
  [] ? system_call_fastpath+0x16/0x1b

on recent kernels.

This is due to commit 8a25a2fd126c ("cpu: convert 'cpu' and
'machinecheck' sysdev_class to a regular subsystem") which renders
commit 6c53cbfced04 ("x86, microcode: Correct sysdev_add error path")
useless.

See http://marc.info/?l=linux-kernel&m=133416246406478

Avoid above warning by restoring the old driver behaviour before
6c53cbfced04 ("x86, microcode: Correct sysdev_add error path").

Cc: Tigran Aivazian 
Signed-off-by: Andreas Herrmann 
Acked-by: Greg Kroah-Hartman 
Link: http://lkml.kernel.org/r/20120411163849.GE4794@alberich.amd.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

sched/x86: Fix overflow in cyc2ns_offset

2012-04-13T16:13:56+00:00

commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 upstream.

When a machine boots up, the TSC generally gets reset.  However,
when kexec is used to boot into a kernel, the TSC value would be
carried over from the previous kernel.  The computation of
cycns_offset in set_cyc2ns_scale is prone to an overflow, if the
machine has been up more than 208 days prior to the kexec.  The
overflow happens when we multiply *scale, even though there is
enough room to store the final answer.

We fix this issue by decomposing tsc_now into the quotient and
remainder of division by CYC2NS_SCALE_FACTOR and then performing
the multiplication separately on the two components.

Refactor code to share the calculation with the previous
fix in __cycles_2_ns().

Signed-off-by: Salman Qazi 
Acked-by: John Stultz 
Acked-by: Peter Zijlstra 
Cc: Paul Turner 
Cc: john stultz 
Link: http://lkml.kernel.org/r/20120310004027.19291.88460.stgit@dungbeetle.mtv.corp.google.com
Signed-off-by: Ingo Molnar 
Cc: Mike Galbraith 
Signed-off-by: Greg Kroah-Hartman