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

perf/x86/intel: Don't accidentally clear high bits in bdw_limit_period()

2018-05-23T01:33:54+00:00

[ Upstream commit e5ea9b54a055619160bbfe527ebb7d7191823d66 ]

We intended to clear the lowest 6 bits but because of a type bug we
clear the high 32 bits as well.  Andi says that periods are rarely more
than U32_MAX so this bug probably doesn't have a huge runtime impact.

Signed-off-by: Dan Carpenter 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sebastian Andrzej Siewior 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: 294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds")
Link: http://lkml.kernel.org/r/20180317115216.GB4035@mwanda
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86/cpu/AMD: Use LFENCE_RDTSC in preference to MFENCE_RDTSC

2018-05-20T03:15:41+00:00

[ Upstream commit 9c6a73c75864ad9fa49e5fa6513e4c4071c0e29f ]

With LFENCE now a serializing instruction, use LFENCE_RDTSC in preference
to MFENCE_RDTSC.  However, since the kernel could be running under a
hypervisor that does not support writing that MSR, read the MSR back and
verify that the bit has been set successfully.  If the MSR can be read
and the bit is set, then set the LFENCE_RDTSC feature, otherwise set the
MFENCE_RDTSC feature.

Signed-off-by: Tom Lendacky 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Reviewed-by: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: Tim Chen 
Cc: Dave Hansen 
Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: Linus Torvalds 
Cc: Greg Kroah-Hartman 
Cc: David Woodhouse 
Cc: Paul Turner 
Link: https://lkml.kernel.org/r/20180108220932.12580.52458.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Sasha Levin

x86/cpu/AMD: Make LFENCE a serializing instruction

2018-05-20T03:15:41+00:00

[ Upstream commit e4d0e84e490790798691aaa0f2e598637f1867ec ]

To aid in speculation control, make LFENCE a serializing instruction
since it has less overhead than MFENCE.  This is done by setting bit 1
of MSR 0xc0011029 (DE_CFG).  Some families that support LFENCE do not
have this MSR.  For these families, the LFENCE instruction is already
serializing.

Signed-off-by: Tom Lendacky 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Reviewed-by: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: Tim Chen 
Cc: Dave Hansen 
Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: Linus Torvalds 
Cc: Greg Kroah-Hartman 
Cc: David Woodhouse 
Cc: Paul Turner 
Link: https://lkml.kernel.org/r/20180108220921.12580.71694.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Sasha Levin

x86/MCE: Serialize sysfs changes

2018-03-21T03:49:50+00:00

[ Upstream commit b3b7c4795ccab5be71f080774c45bbbcc75c2aaf ]

The check_interval file in

  /sys/devices/system/machinecheck/machinecheck

directory is a global timer value for MCE polling. If it is changed by one
CPU, mce_restart() broadcasts the event to other CPUs to delete and restart
the MCE polling timer and __mcheck_cpu_init_timer() reinitializes the
mce_timer variable.

If more than one CPU writes a specific value to the check_interval file
concurrently, mce_timer is not protected from such concurrent accesses and
all kinds of explosions happen. Since only root can write to those sysfs
variables, the issue is not a big deal security-wise.

However, concurrent writes to these configuration variables is void of
reason so the proper thing to do is to serialize the access with a mutex.

Boris:

 - Make store_int_with_restart() use device_store_ulong() to filter out
   negative intervals
 - Limit min interval to 1 second
 - Correct locking
 - Massage commit message

Signed-off-by: Seunghun Han 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: Greg Kroah-Hartman 
Cc: Tony Luck 
Cc: linux-edac 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20180302202706.9434-1-kkamagui@gmail.com
Signed-off-by: Sasha Levin

perf/x86: Shut up false-positive -Wmaybe-uninitialized warning

2018-03-04T15:28:32+00:00

[ Upstream commit 11d8b05855f3749bcb6c57e2c4052921b9605c77 ]

The intialization function checks for various failure scenarios, but
unfortunately the compiler gets a little confused about the possible
combinations, leading to a false-positive build warning when
-Wmaybe-uninitialized is set:

  arch/x86/events/core.c: In function ‘init_hw_perf_events’:
  arch/x86/events/core.c:264:3: warning: ‘reg_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  arch/x86/events/core.c:264:3: warning: ‘val_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     pr_err(FW_BUG "the BIOS has corrupted hw-PMU resources (MSR %x is %Lx)\n",

We can't actually run into this case, so this shuts up the warning
by initializing the variables to a known-invalid state.

Suggested-by: Peter Zijlstra 
Signed-off-by: Arnd Bergmann 
Cc: Alexander Shishkin 
Cc: Andy Lutomirski 
Cc: Arnaldo Carvalho de Melo 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170719125310.2487451-2-arnd@arndb.de
Link: https://patchwork.kernel.org/patch/9392595/
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86/ras/inject: Make it depend on X86_LOCAL_APIC=y

2018-03-04T15:28:28+00:00

[ Upstream commit d4b2ac63b0eae461fc10c9791084be24724ef57a ]

... and get rid of the annoying:

  arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq_ipi’ defined but not used [-Wunused-function]

when doing randconfig builds.

Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: Yazen Ghannam 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/20170123183514.13356-2-bp@alien8.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled

2018-03-01T03:09:41+00:00

[ Upstream commit fac51482577d5e05bbb0efa8d602a3c2111098bf ]

With CONFIG_OF enabled on x86, we get the following error on boot:
"
	Failed to find cpu0 device node
 	Unable to detect cache hierarchy from DT for CPU 0
"
and the cacheinfo fails to get populated in the corresponding sysfs
entries. This is because cache_setup_of_node looks for of_node for
setting up the shared cpu_map without checking that it's already
populated in the architecture specific callback.

In order to indicate that the shared cpu_map is already populated, this
patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
that can be used by the generic code to skip cache_shared_cpu_map_setup.

This patch also sets that boolean for x86.

Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

x86/cpufeatures: Make CPU bugs sticky

2018-03-01T03:09:37+00:00

[ Upstream commit 6cbd2171e89b13377261d15e64384df60ecb530e ]

There is currently no way to force CPU bug bits like CPU feature bits. That
makes it impossible to set a bug bit once at boot and have it stick for all
upcoming CPUs.

Extend the force set/clear arrays to handle bug bits as well.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Dave Hansen 
Cc: David Laight 
Cc: Denys Vlasenko 
Cc: Eduardo Valentin 
Cc: Greg KH 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Will Deacon 
Cc: aliguori@amazon.com
Cc: daniel.gruss@iaik.tugraz.at
Cc: hughd@google.com
Cc: keescook@google.com
Link: https://lkml.kernel.org/r/20171204150606.992156574@linutronix.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86/cpu: Factor out application of forced CPU caps

2018-03-01T03:09:37+00:00

[ Upstream commit 8bf1ebca215c262e48c15a4a15f175991776f57f ]

There are multiple call sites that apply forced CPU caps.  Factor
them into a helper.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Matthew Whitehead 
Cc: Oleg Nesterov 
Cc: One Thousand Gnomes 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Cc: Yu-cheng Yu 
Link: http://lkml.kernel.org/r/623ff7555488122143e4417de09b18be2085ad06.1484705016.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86/microcode/intel: Extend BDW late-loading with a revision check

2018-03-01T03:09:36+00:00

[ Upstream commit b94b7373317164402ff7728d10f7023127a02b60 ]

Instead of blacklisting all model 79 CPUs when attempting a late
microcode loading, limit that only to CPUs with microcode revisions <
0x0b000021 because only on those late loading may cause a system hang.

For such processors either:

a) a BIOS update which might contain a newer microcode revision

or

b) the early microcode loading method

should be considered.

Processors with revisions 0x0b000021 or higher will not experience such
hangs.

For more details, see erratum BDF90 in document #334165 (Intel Xeon
Processor E7-8800/4800 v4 Product Family Specification Update) from
September 2017.

[ bp: Heavily massage commit message and pr_* statements. ]

Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79")
Signed-off-by: Jia Zhang 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Acked-by: Tony Luck 
Cc: x86-ml 
Cc:  # v4.14
Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@alibaba-inc.com
Signed-off-by: Sasha Levin